thắc mắc Hỏi về cách lưu mật khẩu trong database

hieple97

Senior Member
Chào các bác em mới có một dự án kiểu dạng trang mạng xã hội, em đang có một vài thắc mắc về việc mình lưu mật khẩu trong database như thế nào cho an toàn.
Em có xem qua clip của ông bác này:
Trong clip theo em hiểu đại ý ổng nói là:
  • Không nên hash password bởi những thuật toán đơn giản.
  • Nên tạo thêm một random salt rồi chuỗi salt này sẽ được hash cũng với password để phòng chống rainbow attack (tức là mình sẽ lưu trữ hash password và salt trên database)
Em có vài thắc mắc bác nào có kinh nghiệm góp ý giúp:
  • Nếu hacker mà đã lấy được db rồi tức là cả hash password và salt đều bị lộ, như vậy thì đâu có chống lại được rainbow attack ?
  • Em thấy có vài người suggest việc hash password gồm 3 thành phần là password + salt random + secret key (được lưu trên server) như vậy sẽ an toàn hơn vì hacker phải lấy được cả server là db mới có thể đọc được pass user, liệu cách này có an toàn hơn không ạ ?
Mong các bác cho ý kiến.
 
1. Rainbow attack là phải có pre-computed table chứa hashed của các string tương ứng, nhưng giờ kèm salt thì sao rainbow attack được bác? Hay bác nhầm rainbow attack với bruteforce?
2. Chắc chắn là an toàn hơn rồi, bạn có thể tìm hiểu thêm hash + salt + pepper, khái niệm cũng tương tự.
 
Chào các bác em mới có một dự án kiểu dạng trang mạng xã hội, em đang có một vài thắc mắc về việc mình lưu mật khẩu trong database như thế nào cho an toàn.
Em có xem qua clip của ông bác này:
Trong clip theo em hiểu đại ý ổng nói là:
  • Không nên hash password bởi những thuật toán đơn giản.
  • Nên tạo thêm một random salt rồi chuỗi salt này sẽ được hash cũng với password để phòng chống rainbow attack (tức là mình sẽ lưu trữ hash password và salt trên database)
Em có vài thắc mắc bác nào có kinh nghiệm góp ý giúp:
  • Nếu hacker mà đã lấy được db rồi tức là cả hash password và salt đều bị lộ, như vậy thì đâu có chống lại được rainbow attack ?
  • Em thấy có vài người suggest việc hash password gồm 3 thành phần là password + salt random + secret key (được lưu trên server) như vậy sẽ an toàn hơn vì hacker phải lấy được cả server là db mới có thể đọc được pass user, liệu cách này có an toàn hơn không ạ ?
Mong các bác cho ý kiến.
dùng bcrypt để mã hóa nhé thím
 
1. Rainbow attack là phải có pre-computed table chứa hashed của các string tương ứng, nhưng giờ kèm salt thì sao rainbow attack được bác? Hay bác nhầm rainbow attack với bruteforce?
2. Chắc chắn là an toàn hơn rồi, bạn có thể tìm hiểu thêm hash + salt + pepper, khái niệm cũng tương tự.
Ok bác để em research kĩ hơn.
 
Nó đã lấy được db thì quan tâm làm quái gì tới pwd mã hoá ntn nữa.
cái này k phải chỉ phòng ngừa hacker mà là bảo vệ user khỏi chính những người làm quản trị hệ thống. Ngoài ra ko có gì đảm bảo cái data trong table user sẽ ko bao giờ bị leak ra bên ngoài, đơn giản như ông DBA đang mở cái bảng đó ra xem, ai đó vô tình đi qua chụp ảnh được chẳng hạn, passwork clear tech của ai đó sẽ công khai với toàn thế giới.
 
Nó đã lấy được db thì quan tâm làm quái gì tới pwd mã hoá ntn nữa.
1 người có vài chục acc khác nhao, nếu ko xài password manager thì thế lào cũng bị trùng/na ná nhau. Mà lưu password thì phải mặc định là sẽ bị hack. Giả sử cái shop rác có password trùng với account khác giá trị hơn, shop rác bị hack mà ko hash pw cho đúng thì bị lộ raw password, trùng với account giá trị hơn thì béo thằng nắc cơ
1BW9Wj4.png
Nếu ko có gì bảo đảm shop rác lưu password đúng thì thằng lào dám tạo acc shop rác nữa
KgmQHtR.png
mà ko ai xài web của shop nhỏ lẻ thì doanh nghiệp nhỏ lẻ làm xao cạnh tranh với doanh nghiệp lớn được, thằng lớn nó độc quyền nó tăng giá ko thể chấp nhận được
aVgiONl.png
Thế nên dù là web rác vẫn phải hash pw cho đúng cách
Xv0BtTR.png


có thể có ý kiến khác là xài oauth gì đó của gg/fb, cách này rất tiện và mình ko phải mất công lưu pw nhưng lỡ người dùng bị ban gg thì bỏ mẹ cái acc của người ta ở trang web rác xài oauth đó. Như acc Kute v3 này của toy xài gmail tạo mới nó phát hiện toy spam gmail nó ban ròi, toy chủ quan đéo ngờ nó ban nên đéo tạo password cho cái acc này, lịt pẹ lỡ log out ra là đéo log in vào được nữa luôn
LTT2cUR.png
LTT2cUR.png
LTT2cUR.png
(tuy nhiên phò rum này là web rác, toy đã lưu cái cookie xf_user lại có gì xài để login vào
Dcnffay.png
) Lưu password vẫn phải cần chứ ko phó mặc cho oauth được
Dcnffay.png
 
Nó đã lấy được db thì quan tâm làm quái gì tới pwd mã hoá ntn nữa.
Chủ yếu là bảo vệ user trước mấy ông vận hành hệ thống thôi, kiểu như bạn làm bên Facebook, sau bạn nghỉ việc thì bạn cũng ko thể nào login vào account user cho dù trước đó bạn đã thực sự sở hữu DB user và bạn đã backup nó về local của bạn
 
1 người có vài chục acc khác nhao, nếu ko xài password manager thì thế lào cũng bị trùng/na ná nhau. Mà lưu password thì phải mặc định là sẽ bị hack. Giả sử cái shop rác có password trùng với account khác giá trị hơn, shop rác bị hack mà ko hash pw cho đúng thì bị lộ raw password, trùng với account giá trị hơn thì béo thằng nắc cơ
1BW9Wj4.png
Nếu ko có gì bảo đảm shop rác lưu password đúng thì thằng lào dám tạo acc shop rác nữa
KgmQHtR.png
mà ko ai xài web của shop nhỏ lẻ thì doanh nghiệp nhỏ lẻ làm xao cạnh tranh với doanh nghiệp lớn được, thằng lớn nó độc quyền nó tăng giá ko thể chấp nhận được
aVgiONl.png
Thế nên dù là web rác vẫn phải hash pw cho đúng cách
Xv0BtTR.png


có thể có ý kiến khác là xài oauth gì đó của gg/fb, cách này rất tiện và mình ko phải mất công lưu pw nhưng lỡ người dùng bị ban gg thì bỏ mẹ cái acc của người ta ở trang web rác xài oauth đó. Như acc Kute v3 này của toy xài gmail tạo mới nó phát hiện toy spam gmail nó ban ròi, toy chủ quan đéo ngờ nó ban nên đéo tạo password cho cái acc này, lịt pẹ lỡ log out ra là đéo log in vào được nữa luôn
LTT2cUR.png
LTT2cUR.png
LTT2cUR.png
(tuy nhiên phò rum này là web rác, toy đã lưu cái cookie xf_user lại có gì xài để login vào
Dcnffay.png
) Lưu password vẫn phải cần chứ ko phó mặc cho oauth được
Dcnffay.png
Thank bác đã cho mình thêm một góc nhìn
 
haha. vậy là giờ không thể decrypt lại cái pass đó để xem mà chỉ có thể mã hóa 1 chiều pass nhập vô rồi so sánh với chuỗi trong csdl à bác?
Mình hiểu là nhập password đó vào giống ban đầu rồi encrypt lại generate ra chuỗi hash ra lại sẽ giống chuỗi hash với mật khẩu đó. Kiểu Key Value á.
 
Back
Top