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
Hi, mình cảm ơn ý kiến của bạn. Thật ra mình cũng thấy hơi cảm tính vì bài viết đây chỉ là những gì mình đọc từ paper của họ chứ mình thật sự chưa có sự tham gia như vậy nhiều trong thực tế nên mình không thể đưa ra ý kiến khách quan. Có thể trong tương lai nếu có cơ hội mình sẽ refactor lại bài viết này 😂 Cảm ơn ý kiến của bạn nhé.
Em cũng đang bắt đầu con đường khá giống anh , những profile em còn cùi bắp hơn cả anh
Học hết lớp 12 rồi lên bình dương làm công nhân nhà máy đi xoaay ca 12 ( đuối như c hó , tưởng nghiện không )
Làm tới năm 2021 thì dịch tới bị nhốt lại 3 tháng sống trong căn phòng tâm tối , chỉ có ăn rau với trứng mì tôm mà sống qua ngày
_ Khi đó em nghĩ mình phải làm gi khác mới có thể thay đổi được tương lại ( chả lẽ lam công nhân quèn cả đời )
Tích góp được một ít đăng ký vào Cao đăng FPT học cho nó lẹ (Lúc cũng theo IT, mặc dù máy tính chưa biết sài lun)
Rồi cũng cố gắn mua laptop về mò này kia , coi ytb học tập, năm nhất học online do còn dịch , học xong chả hiểu gi hết ( tính bỏ ngang không biết bao lần )
Rồi sau năm 2022 lên tp đi học , chạy shipper kiếm sống , kiếm tiền ăn , đi bưng bàn , chiên gà , lam đủ nghề trang trãi cuộc sống
sang năm 2023 lúc này cũng đỡ hơn , code cũng ổn rồi ( mới nhận làm bai tập sinh viêm , code web nhỏ nhỏ , cuộc sống cũng đỡ cực hơn )
Cuối năm 2023 em ra trường với tấm bằng Loại giỏi GPA 3.4 , có lam 1 cty đâu tiên ở bình thạnh nhưng thấy ko phù hợp mấy nên out.
Bước sáng 2024 em lại quay lại bình dương , nhưng lúc này làm IT cho một cty ( chứ méo còn là thằng công nhân nghiện ngày xưa)
Hiện tại làm vp 8 tiếng về , tối lam thêm freelancer , ngày nào cung học thêm english ( xưa 45kg - m7 = > bây giờ 65-m73 có body tập gym tí , da trắng hơn )
Không bao giờ bỏ cuộc . Đừng trách số phận mà hãy cố gắn hết sức !
a ơi cho e hỏi về việc cập nhật lại name script chứa hash vào file html là làm cách nào ạ. Ngoài cách viết thêm 1 script chạy để io getname script file sau đó sửa lại file html thì còn cách nào không ạ. mong anh chỉ giáo ạ.
THẢO LUẬN
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 ạ ?
Hi, mình cảm ơn ý kiến của bạn. Thật ra mình cũng thấy hơi cảm tính vì bài viết đây chỉ là những gì mình đọc từ paper của họ chứ mình thật sự chưa có sự tham gia như vậy nhiều trong thực tế nên mình không thể đưa ra ý kiến khách quan. Có thể trong tương lai nếu có cơ hội mình sẽ refactor lại bài viết này 😂 Cảm ơn ý kiến của bạn nhé.
Em cũng đang bắt đầu con đường khá giống anh , những profile em còn cùi bắp hơn cả anh
Không bao giờ bỏ cuộc . Đừng trách số phận mà hãy cố gắn hết sức !
khúc tạo ra session key có sử dụng diffie hellman key exchange k ạ
a ơi cho e hỏi về việc cập nhật lại name script chứa hash vào file html là làm cách nào ạ. Ngoài cách viết thêm 1 script chạy để io getname script file sau đó sửa lại file html thì còn cách nào không ạ. mong anh chỉ giáo ạ.
@ngocanh208 bạn ơi bài của bạn hay quá có thể cho mình xin tài liệu dc không ạ. qa002d1@gmail.com
cám ơn bạn đã thích bài viết