Re:Digital Identity Guidelines: Public Comment Period
by Freak_NL on Monday March 13, 2017 @07:04AM
(#13856749)
If you are not reusing passwords, you should (from a security standpoint) not care at all. Without client-side hashing the server gets a bunch of characters that are exclusively used for that service, and with hashing it gets another bunch of characters.
The only situation where client-side hashing could matter is if you are reusing passwords; but the user can trivially mitigate that by not reusing passwords in the first place.
From the standpoint of the operator providing the service, security is not increased by one iota by hashing on the client. In fact, it can decrease security. By following the NIST guidelines, most up-front password rules are relaxed. However, to guarantee password strength, NIST recommends to do a check against common password lists and dictionaries to guarantee a certain level of entropy. So even if you meet the minimum length check, a password like 'password1980' should fail (common password plus a year). This check cannot easily be done client-side, because from a security standpoint the client is untrusted (especially so with HTTP and HTML/CSS/JavaScript) and it would require a substantial amount of data to be sent to the client (password databases, word lists, etc.). Even without these additional checks, the server still needs to know if your password meets the minimum length requirement. It can only do this reliably by inspecting the password (again, assuming a web browser is the client).
So when you enter a new password, the server should check if the minimum length and optionally the minimum entropy are met. At that point the server already 'knows' your password, so client-side hashing whenever you login normally is redundant.
The only situation where client-side hashing could matter is if you are reusing passwords; but the user can trivially mitigate that by not reusing passwords in the first place.
From the standpoint of the operator providing the service, security is not increased by one iota by hashing on the client. In fact, it can decrease security. By following the NIST guidelines, most up-front password rules are relaxed. However, to guarantee password strength, NIST recommends to do a check against common password lists and dictionaries to guarantee a certain level of entropy. So even if you meet the minimum length check, a password like 'password1980' should fail (common password plus a year). This check cannot easily be done client-side, because from a security standpoint the client is untrusted (especially so with HTTP and HTML/CSS/JavaScript) and it would require a substantial amount of data to be sent to the client (password databases, word lists, etc.). Even without these additional checks, the server still needs to know if your password meets the minimum length requirement. It can only do this reliably by inspecting the password (again, assuming a web browser is the client).
So when you enter a new password, the server should check if the minimum length and optionally the minimum entropy are met. At that point the server already 'knows' your password, so client-side hashing whenever you login normally is redundant.