3 ms·

As a user, any password you supply should always be treated as a shared secret between you and the service. We are well past the age of using the same password

As a user, any password you supply should always be treated as a shared secret between you and the service. We are well past the age of using the same password for everything. Agreed, but that does not change the fact that you shouldn't be sending the password to the server, since that is thrusting that the server handles it correctly. If you gurantee that passwords will never be reused, the password is as good a secret as the hash. But if you cannot gurantee this, and that includes nearly all real world systems with humans users, it makes an important difference security wise.

Freak_NL 10y ago
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.
hvidgaard 10y ago
Replying to Freak_NL here since I cannot make the thread deeper. If you are not reusing passwords, you should (from a security standpoint) not care at all. From a user stand point I agree. But that is not what I'm tryin to argue. From the standpoint of the operator providing the service, security is not increased by one iota by hashing on the client. That is not true - it absolutely matters for service providers. If my service verifiably hash client side, and I only ever see the hash, I can gurantee that in the scenario where the database is breached only a hash is leaked. When my service cannot verify, enforce, or reasonably gurantee that users do not reuse passwords, it means that in the event of a breach less information is leaked. > 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 yo 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). The password list to check against is at worst a few megabytes. Considering that we have JS libs that are larger, I fail to see this as a significant issue. Besides we already know how to encrypt such that I can send an encrypted password to you, where you can, without knowing the key, can verify simple claims about the data. 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. If we accept your thesis that we must send the password to the server upon changing it, we could still use client side hashing for a marginally improved security model.
- Freak_NL 10y ago
  > The password list to check against is at worst a few megabytes. People stuck on a slow mobile network would tend to disagree. > Besides we already know how to encrypt such that I can send an encrypted password to you, where you can, without knowing the key, can verify simple claims about the data. The server can't verify such claims without actually inspecting the password because the client is (from a security standpoint) untrusted. In the HTTP/HTML web client/server model, there is no effective way for the server to guarantee that the client is truthfully executing certain algorithms. That's fine, but it does mean that the server is the only source of truth for these type of security claims. > If we accept your thesis that we must send the password to the server upon changing it, we could still use client side hashing for a marginally improved security model. That's a dangerous road to take. Such a marginal security improvement still comes at a cost of increased complexity and maintenance burden. If users don't like the idea of sending passwords to a remote server, they should request that the service implements a two-factor authentication solution instead.

Freak_NL 10y ago

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.

hvidgaard 10y ago

Replying to Freak_NL here since I cannot make the thread deeper. If you are not reusing passwords, you should (from a security standpoint) not care at all. From a user stand point I agree. But that is not what I'm tryin to argue. From the standpoint of the operator providing the service, security is not increased by one iota by hashing on the client. That is not true - it absolutely matters for service providers. If my service verifiably hash client side, and I only ever see the hash, I can gurantee that in the scenario where the database is breached only a hash is leaked. When my service cannot verify, enforce, or reasonably gurantee that users do not reuse passwords, it means that in the event of a breach less information is leaked. > 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 yo 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). The password list to check against is at worst a few megabytes. Considering that we have JS libs that are larger, I fail to see this as a significant issue. Besides we already know how to encrypt such that I can send an encrypted password to you, where you can, without knowing the key, can verify simple claims about the data. 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. If we accept your thesis that we must send the password to the server upon changing it, we could still use client side hashing for a marginally improved security model.

Freak_NL 10y ago
> The password list to check against is at worst a few megabytes. People stuck on a slow mobile network would tend to disagree. > Besides we already know how to encrypt such that I can send an encrypted password to you, where you can, without knowing the key, can verify simple claims about the data. The server can't verify such claims without actually inspecting the password because the client is (from a security standpoint) untrusted. In the HTTP/HTML web client/server model, there is no effective way for the server to guarantee that the client is truthfully executing certain algorithms. That's fine, but it does mean that the server is the only source of truth for these type of security claims. > If we accept your thesis that we must send the password to the server upon changing it, we could still use client side hashing for a marginally improved security model. That's a dangerous road to take. Such a marginal security improvement still comes at a cost of increased complexity and maintenance burden. If users don't like the idea of sending passwords to a remote server, they should request that the service implements a two-factor authentication solution instead.