Khai thật đi, ai đang lưu password của user vào database như thế này không (Hình 2)? Nếu có thì dừng ngay lại và ngay lập tức cập nhật lại phương thức theo bài viết này giúp tui nha.
Mất việc đấy, không đùa đâu!
Bạn là một Backend Engineer hay một Data Engineer, bạn là người cầm nắm thông tin của khách hàng, của người dùng, thì có một số thứ sau đây bạn không nên làm với mật khẩu của người dùng nha:
1. Lưu password dưới dạng plain text như hình mô tả trên, nói nôm na là password người dùng nhập vào là gì bạn lưu nguyên xi như vậy vào trong DB. Điều này rất nguy hiểm khi mà bất kỳ ai trong nội bộ công ty có quyền vào DB đều có thể nhìn thấy những thông tin này, và giả sử khi có vấn đề xảy ra thì rất khó điều tra nguyên nhân.
2. Lưu trực tiếp phiên bản hashing của password để đảm bảo an toàn là một phương án khá là khả dĩ cách đây độ chục năm. Tuy nhiên giờ thì nó không đủ để ngăn các cuộc tấn công từ bên ngoài nữa. Giờ có các kiểu tấn công như là rainbow tables để càn quét password của user. Các ace có thể tìm hiểu thêm về cách tấn công này qua keyword trên ha 😀
Vậy để giảm thiểu khả năng bị “hack” mất mật khẩu người dùng, các kỹ sư có thể áp dụng phương thức là “Password salting”.
Theo định nghĩa thì: Salt là một chuỗi string được tạo ra ngẫu nhiên và là duy nhất, nó được thêm vào mỗi password như là một phần của quá trình Hashing. Nghe có vẻ trừu tượng nhỉ =.=
Đi chi tiết nhé:
- CÁCH LƯU PASSWORD VÀ SALT
1. Nhìn hình thấy rõ ràng hơn đúng không ace, Client cung cấp password cho hệ thống, ngay lập tức một chuỗi salt được sinh ra (ngẫu nhiên nhé). Lưu luôn cái Salt này vô cái DB nhé.
2. Còn cái Hash thì không đơn giản là Hash mỗi password nữa mà hash luôn cả password+salt rồi lưu vô DB như chúng ta thấy trên hình.
Lưu ý: Salt không có nghĩa là bảo mật, nó có thể lưu dưới dạng plain text cơ bản trong DB. Chức năng của nó là đảm bảo kết quả hash là duy nhất cho mỗi password.
- CÁCH VALIDATE PASSWORD:
1. Client nhập password vô hệ thống 2. Hệ thống ngay lập tức lấy cái salt tương ứng trong DB 3. Hệ thống kết hợp salt với password rồi hash nó. Tạm gọi kết quả sau khi hash xong là H1 4. Với kết quả hash từ từ trước đó khi mà người dùng mới đăng ký password, ta gọi nó là H2 đi. Nếu H1=H2 thì ok, password đúng, client được quyền truy cập vô hệ thống.
Đó, đơn giản đúng không bà con, thực ra chân ái ở đây chỉ là thêm một chút gia vị “muối” để những kỹ thuật như rainbow tables khó khăn hơn trong việc tấn công hệ thống mật khẩu. Vì dù sao đống muối này là do chúng ta tạo ra phía hệ thống mà mình quản lý nên cũng giúp hệ thống mặn hơn ha 😀 Hi vọng chia sẻ ngắn gọn trên giúp anh chị em dễ dàng follow theo và áp dụng vào trong hệ thống của mình nhé. Anh em thấy chỗ nào chưa hợp lý thì để lại feedback ha 😀
Thanks, tui là Huy Đê Tê
Kỹ năng nghề nghiệp Kỹ năng mềm Ngành IT Các ngành nghề khác Ngành Kinh tế