Tôi không có nghĩa là tạo một hàm băm ở phía máy khách và sau đó lưu trữ nó trực tiếp trong cơ sở dữ liệu. Tôi đã tìm thấy một số câu hỏi có chủ đề tương tự, nhưng hầu hết các câu trả lời đó đều giả định một tình huống trong đó mật khẩu được gửi qua các kết nối không được mã hóa hoặc hàm băm của ứng dụng khách được lưu trữ trực tiếp trong cơ sở dữ liệu.
(1) Kịch bản mà tôi đang mô tả là một bước bổ sung ngoài quy trình công việc hiện có, trong đó người dùng gửi văn bản gốc thông qua kết nối https và máy chủ băm nó bằng muối và lưu trữ hàm băm và muối trong cơ sở dữ liệu. Vì vậy, thay vì gửi mật khẩu thực tế, điều gì sẽ xảy ra nếu hàm băm được tính toán ở phía máy khách và gửi đến máy chủ. Sau đó, đối với tất cả ý định và mục đích, máy chủ sẽ coi hàm băm ứng dụng khách ban đầu này là mật khẩu văn bản gốc của người dùng và sau đó băm lại với muối bằng phương pháp băm của chính nó như thường làm. Trong trường hợp máy chủ vô tình ghi nhật ký nhập mật khẩu của người dùng (ví dụ: trong khi gỡ lỗi), mật khẩu thực sẽ vẫn an toàn.
(2) Ngoài ra, nếu băm phía máy khách không phải là một phương pháp bảo mật tồi, thì sao về việc thêm một chuỗi chung duy nhất vào ứng dụng (ví dụ: tên miền của ứng dụng) hoặc một chuỗi duy nhất (ví dụ: tên người dùng) vào mật khẩu của người dùng trước khi băm để đảm bảo rằng hàm băm của ứng dụng khách cho cùng một mật khẩu sẽ khác với hàm băm tương tự do ứng dụng khác tạo ra. Vị trí của một chuỗi như vậy (được nối thêm hoặc thêm vào trước) có quan trọng không.
Một vấn đề tôi có thể nghĩ đến là máy chủ sẽ không thể thực thi độ phức tạp của mật khẩu cụ thể đối với người dùng. Người dùng vẫn có thể được cảnh báo (hoặc mật khẩu có thể bị từ chối) ở phía máy khách, nhưng người dùng vẫn có thể chọn bỏ qua nó và gửi qua bất kỳ chuỗi nào có cùng độ dài với độ dài hàm băm dự kiến.
