3 ms·
Client side hashing solves only one aspect of the problem. Effectively, this means a password breach of your service will give the attacker a “password equivale
by matthewdgreen 8y ago
Client side hashing solves only one aspect of the problem. Effectively, this means a password breach of your service will give the attacker a “password equivalent” that they can subsequently use to log into the service without further cracking. This may or may not be a problem, depending on whether you’re willing to lock all user accounts.
Whereas a proper asymmetric PAKE means that even if your password file is breached, the attacker can’t use the leaked hashes to log into the service without first cracking each password.
The problem you point out: that password hashes can be brute-force cracked, is unfortunately not a problem we can solve. Consider that a server can always “attempt a login to itself”, so given a password database you can always run a dictionary attack. The only thing truly protecting you in that case is the combination of strong passwords and a hard password hashing algorithm. Passwords are fundamentally a drag.
- kijin 8y agoIt's not all-or-nothing. You can hash passwords on the client side, and hash it some more on the server side before committing the final result to permanent storage. A breach of your database won't give the attacker a password equivalent in that case.
- xyzzy123 8y ago[Orthogonally to client-side hashing] Using a hardware one-way function you can ensure that even if your database is breached or disclosed, attackers cannot brute-force outside of your environment (e.g. the hashed are “anchored” to your systems). You can construct such a function using something like CloudHSM (pity that KMS cannot be coaxed to be deterministic or you could use that). All you need is an encrypt operation with no corresponding decrypt or way to extract the key. I’m surprised that more large online services don’t use anchoring.