4 ms·

Hashing the password client-side just means that the hash is now the password. Storing that hash is no different than storing the password, and when someone dum

Hashing the password client-side just means that the hash is now the password. Storing that hash is no different than storing the password, and when someone dumps out your database they can log in directly with the hash, because it's the password. So you still need to take all the same precautions you would with the original password, including hashing it again. For your trouble here you get essentially no security value, assuming you're doing everything else right, but do get some additional risk thanks to the extra moving part. There are however real schemes to avoid transmitting passwords that may interest you, like PAKEs: https://en.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.wikipedia.org/wiki/Password-authenticated_key_agr.... But there are still compelling reasons not to use these, e.g. https://palant.info/2018/10/25/should-your-next-web-based-login-form-avoid-sending-passwords-in-clear-text/ https://palant.info/2018/10/25/should-your-next-web-based-lo....

suriyaG 4y ago
I'm confused. How is it possible to login directly with the hash? I was under the impression that if you use the hashed password obtained from the DB, then the system will try to match the hash of the hash and would fail because they would be different.
- aobdev 4y ago
  They’re talking specifically about client-side hashing. You’re right that the system will hash the stolen hash, but only in cases where the system can’t be bypassed (which client side code always can be).
- FreakLegion 4y ago
  You're not wrong. To clearly delineate the two possibilities: 1. Hashing client-side in addition to standard server-side handling (Have I Been Pwned passwords disallowed, good hash function, preferably memory-hard, salted, peppered for storage, etc.). In this case client-side hashing adds complexity but doesn't improve the security model at all, so we shouldn't do it. Which is why nobody does it. 2. Hashing client-side instead of standard server-side handling. In this case client-side hashing completely breaks the security model, since the hash is equivalent to a cleartext password, so we shouldn't do it. Besides random websites, this kind of mistake has actually been made at scale. See https://en.wikipedia.org/wiki/Pass_the_hash https://en.wikipedia.org/wiki/Pass_the_hash. In summary, basic client-side hashing either doesn't improve security or compromises it, and is therefore best avoided.

suriyaG 4y ago

I'm confused. How is it possible to login directly with the hash? I was under the impression that if you use the hashed password obtained from the DB, then the system will try to match the hash of the hash and would fail because they would be different.

aobdev 4y ago
They’re talking specifically about client-side hashing. You’re right that the system will hash the stolen hash, but only in cases where the system can’t be bypassed (which client side code always can be).
FreakLegion 4y ago
You're not wrong. To clearly delineate the two possibilities: 1. Hashing client-side in addition to standard server-side handling (Have I Been Pwned passwords disallowed, good hash function, preferably memory-hard, salted, peppered for storage, etc.). In this case client-side hashing adds complexity but doesn't improve the security model at all, so we shouldn't do it. Which is why nobody does it. 2. Hashing client-side instead of standard server-side handling. In this case client-side hashing completely breaks the security model, since the hash is equivalent to a cleartext password, so we shouldn't do it. Besides random websites, this kind of mistake has actually been made at scale. See https://en.wikipedia.org/wiki/Pass_the_hash https://en.wikipedia.org/wiki/Pass_the_hash. In summary, basic client-side hashing either doesn't improve security or compromises it, and is therefore best avoided.