5 ms·
Why not have one round of hashing in the browser? That way the input to your server-side hash function is fixed-length, whether the users password is 20 charac
by hannasanarion 7y ago
Why not have one round of hashing in the browser?
That way the input to your server-side hash function is fixed-length, whether the users password is 20 characters or 20 billion, and DOS attackers are only hurting their own computers.
- zeta0134 7y agoWouldn't that just turn the attacker's problem into brute forcing the client-side hash? Might be a problem if the client-side hash has a lower total complexity than the longer original password. I dunno though; just pondering out loud, I'm by no means an expert on this stuff.
- eru 7y agoYes, obviously. So you choose something like 1024 bits as the length of the client hash. The client hash doesn't even need to be any good, even xor-ing blocks might work. It just needs to preserve a lot of entropy.
- hannasanarion 7y agoBut the hash would necessarily preserve the entropy of the password. A 256 bit hash is about as strong as a 32 character random password. According to the password haystack, that would take "6.22 hundred trillion trillion trillion trillion centuries" to crack in an online attack. If you choose to attack such a scheme by guessing the hash, then all passwords have that same level of entropy, even if the password that generated the hash is only 8 characters.