Bạn viết bài chia sẻ chi tiết cho m.n đi. Với các bạn đang bắt đầu hoặc đang hoang mang thì những cái này mình nghĩ khá cần thiết. Không phải ai bước ra khỏi cổng trường cũng pro luôn được á. Chúc bạn thành công nhé.
Mình nghĩ là cũng có thể tạo một cơ chế sinh ngẫu nhiên ra salt. Với salt có đội dài tương đối, và quá trình sinh ra salt tốt thì cũng bảo mật hơn việc lưu salt.
VD như mình sinh ngẫu nhiên một chuỗi 8 ký tự với seed là username của người dùng. Salt sinh ra bằng code, nên trừ khi đoán được cơ chế sinh ra salt, hoặc có được đoạn code sinh ra salt thì hacker mới biết salt của một tài khoản là gì. Bởi username không thể trùng nhau, nên salt được sinh ngẫu nhiên ra gần như không thể trùng nhau được. => Đảm bảo yếu tố salt của mỗi tài khoản khác nhau.
Độ dài chuỗi salt càng lớn => càng bảo mật, càng đảm bảo mỗi salt là duy nhất.
a thấy việc remove token bị hết hạn này thường là low-priority (thường thôi chứ ko phải tất cả trường hợp)
và cơ chế remove thì có nhiều cách, ở đây a nghĩ nhanh 2 cách:
đơn giản nhất là chạy cronjob
hoặc ko thì chờ lần tiếp theo user login vào thì xoá token cũ và tạo cái mới (cái này ưu điểm là ko chạy cronjob mà chỉ làm với những user thực sự quay lại, nhược điểm là nhiều user ko quay lại thì tốn resource db)
Mình muốn hỏi vấn đề sau ạ:
Trong trường hợp có dùng salt và mỗi user có 1 giá trị salt khác nhau thì giá trị này nên được lưu ở đâu ạ
Nếu lưu trực tiếp vào db kiểu như sau thì mình thấy không ổn lắm
THẢO LUẬN
Mong bạn ra thêm nhiều bài viết hơn nữa!
cảm ơn bạn, bài viết rất hay!
mình ko dung telegram, bạn có mail mình gửi cho.
Cho mình hỏi có cách nào để thay tên logo samsung thành tên mình được không !? Cảm ơn!!!
Mình đang làm cho một công ty chứng khoán của VN thôi. code bình thường ấy mà
Bạn viết bài chia sẻ chi tiết cho m.n đi. Với các bạn đang bắt đầu hoặc đang hoang mang thì những cái này mình nghĩ khá cần thiết. Không phải ai bước ra khỏi cổng trường cũng pro luôn được á. Chúc bạn thành công nhé.
Mình nghĩ là cũng có thể tạo một cơ chế sinh ngẫu nhiên ra salt. Với salt có đội dài tương đối, và quá trình sinh ra salt tốt thì cũng bảo mật hơn việc lưu salt.
VD như mình sinh ngẫu nhiên một chuỗi 8 ký tự với seed là username của người dùng. Salt sinh ra bằng code, nên trừ khi đoán được cơ chế sinh ra salt, hoặc có được đoạn code sinh ra salt thì hacker mới biết salt của một tài khoản là gì. Bởi username không thể trùng nhau, nên salt được sinh ngẫu nhiên ra gần như không thể trùng nhau được. => Đảm bảo yếu tố salt của mỗi tài khoản khác nhau.
Độ dài chuỗi salt càng lớn => càng bảo mật, càng đảm bảo mỗi salt là duy nhất.
@Duc_Thang_2000 sorry e a bỏ lỡ comment này
a thấy việc remove token bị hết hạn này thường là low-priority (thường thôi chứ ko phải tất cả trường hợp)
và cơ chế remove thì có nhiều cách, ở đây a nghĩ nhanh 2 cách:
Thế này chỉ là đơn giản thôi, có cả AI nữa mới đúng
vẫn phải thế thôi bạn ạ , lưu vào database , hacker hack đc pass và salt , hacker sử dụng rainbow table thì cũng sẽ mất time hơn
♥️
Mình muốn hỏi vấn đề sau ạ:
Trong trường hợp có dùng salt và mỗi user có 1 giá trị salt khác nhau thì giá trị này nên được lưu ở đâu ạ
Nếu lưu trực tiếp vào db kiểu như sau thì mình thấy không ổn lắm
👍️
@viquang Cố lên bạn, mà tới lúc đó viết bài mới ok hơn.
user/password root chỉ sử dụng cho lần cài đặt đầu tiên
bài viết hay quá, cho mình xin bản gốc markdown qua telegram @nguyentranchung được k ạ
Mạnh dạn viết 1 bài riêng chia sẻ tâm sự để mọi người cùng đọc, cùng chiêm nghiệm thôi bác ơi 😁
Bạn có thể nói rõ hơn chỗ này Canva làm bằng cách nào được không : Để di chuyển những media còn lại sang DynamoDB, Canva sẽ quét qua tất cả các media,
giờ a đang làm bên j ạ ?