2 ms·
That's true, the hashing should definitely be done as early as possible. "As early as possible" is interesting. It could be done on the client, however you nee
by Wingy 3y ago
That's true, the hashing should definitely be done as early as possible.
"As early as possible" is interesting. It could be done on the client, however you need to actually have the hash to check if a string hashes to the same as it because of the salts embedded in the strings. Using an algorithm without salting would allow you to hash the password on the client then allow arbitrary 32 (or however long your hash digests are) character strings on the server as a password equivalent. This would also protect from a misconfigured or malicious server logging unhashed passwords.
- duskwuff 3y ago> It could be done on the client No, that's actually too early -- if you let the client hash the password, you're vulnerable to a "pass-the-hash" attack where the client submits a hash without knowing the password. There are protocols like SRP and other PAKEs which allow this to be done securely, but it's uncommon for them to be used in web applications.
- Wingy 3y agoMy reasoning was that if you can capture the hash, you could have also captured the password but that doesn't account for a situation where the database is compromised.