Cách tốt nhất để băm mật khẩu người dùng tại trình duyệt máy khách là gì, trước khi gửi nó đến máy chủ web, để chỉ băm ra ngoài, không phải mật khẩu thuần văn bản?Mật khẩu băm tại trình duyệt của khách hàng
EDIT: giả sử HTTP được sử dụng (không HTTPS)
Sử dụng javascript để tính toán băm. Xem this để biết ví dụ về cách tính băm SHA-1 trong JS.
Hãy coi chừng nếu bạn tự làm mình phụ thuộc vào Javascript, hệ thống của bạn sẽ không thành công ngay khi có ai đó đã tắt JS. Bạn nên sử dụng HTTPS nếu điều này là mối quan ngại đối với bạn, điều này có những trở ngại riêng (ví dụ: chứng chỉ chi phí tiền nếu bạn muốn chúng được các trình duyệt chấp nhận ngay lập tức.)
Không phải tất cả mọi người đều đã bật JavaScript trong trình duyệt của họ và thậm chí cả ý tưởng gửi băm trên một kênh văn bản thuần túy tôi nghĩ là không đủ an toàn.
Tôi khuyên bạn nên xem xét kết nối an toàn SSL.
Hãy thử sử dụng số jQuery encryption plugin này. Ngoài sự tò mò, có gì sai khi sử dụng SSL/HTTPS và mã hóa ở phía máy chủ?
Tôi giả sử làm việc trên HTTP đơn giản – Andy
Trang web này có khá toàn diện thứ băm/crypto: JavaScript Encryption Library
mã hóa JavaScript phía như thư viện jQuery Encryption dừng nghe trộm. Tuy nhiên, MITM (Man-in-the-Middle) vẫn có thể xảy ra. SSL/TLS là lựa chọn cuối cùng được khuyến nghị thực hiện trừ khi bạn đang ở trên lưu trữ được chia sẻ (không có IP chuyên dụng) hoặc trang web của bạn đang nhận được rất nhiều lưu lượng truy cập mà bạn không thể mã hóa tất cả các kết nối (JS, CSS, HTML, .. .).
Tại sao bạn lại bận tâm đến việc này? Hiệu quả, mật khẩu băm đã trở thành mật khẩu và một người đàn ông-trong-the-giữa những người chặn các băm có thể sử dụng nó để xác thực và thực hiện bất kỳ hành động như người sử dụng. Mặt khác, nếu bạn không tin vào người đàn ông ở giữa, tại sao không chỉ gửi mật khẩu?
Thách thức-Phản hồi bảo vệ chống lại Eavesdropping-nơi bạn không thể thay đổi bất kỳ dữ liệu nào, nhưng chỉ cần nghe nó. Vì thẻ chỉ là một lần duy nhất, người nghe trộm sẽ luôn bị trễ và không sử dụng mã thông báo. – Tower
Vâng, đó là sự thật, tôi cho rằng nó sẽ ngăn chặn kẻ tấn công nghe lén chỉ khám phá ra mật khẩu. Nhưng trong trường hợp đó, tôi chỉ cần sử dụng xác thực HTTP Digest thay vì tự mình cuộn. – erickson
Tại sao chúng tôi băm mật khẩu? Vì vậy, nếu băm thu được chúng rất khó sử dụng.
Điều gì sẽ xảy ra trong mô hình này nếu các băm trong hệ thống bị lộ? Kẻ tấn công chỉ cần gửi chúng đến máy chủ và xác thực là người dùng.
Đây là lý do tại sao băm mật khẩu luôn xảy ra trên máy chủ chứ không phải máy khách!
Tôi hy vọng bạn dự định gửi mã băm qua kênh bảo mật hoặc đây là một phần của cơ chế thách thức/phản hồi. Nếu không, điều này không an toàn hơn việc gửi mật khẩu bằng văn bản thuần túy ... –
@Roger Lipscombe, phương pháp này thực sự có thể là một cải tiến nhỏ cho người dùng. Ngay cả khi không có một kênh an toàn có sẵn (chỉ SSL sẽ hoạt động, không có thay thế JS nào sẽ là chống đạn) thì ít nhất nó sẽ làm cho hàm băm duy nhất cho trang web. Để làm cho băm duy nhất, tất nhiên, * nó phải được muối *. – Inshallah
Cấp rằng nó sẽ làm cho hàm băm duy nhất cho trang web - hữu ích nếu người dùng sử dụng cùng một mật khẩu trên nhiều trang web; không ngăn phát lại trên cùng một trang web. Và, chắc chắn nếu băm được muối, sau đó hoặc là muối phải đi từ khách hàng đến máy chủ - không an toàn hơn trước; hoặc cách khác, trong trường hợp đó, nó là thách thức/phản hồi. –