4 ms·
no that's not how it works. If the client could simply send a hashed password over as an authenticator, then hashing the password database would provide no pro
by dbt00 8y ago
no that's not how it works.
If the client could simply send a hashed password over as an authenticator, then hashing the password database would provide no protection against theft, because you could simply use the stored hash as the password. This solution would only protect users from password reuse from theft.
Hashing with a negotiated salt and computing client and server side protects the password in transit but means storing the password in plaintext on the server. We use TLS (or SSH, or other encrypted protocols) to protect passwords in-flight instead, and hash passwords on the server to protect them from theft.
(Remember, the original attack password hashing was protecting against was a world readable file that contained all usernames and passwords, /etc/passwd on Unix. Eventually the world moved to "shadowed" passwords, where the hashes were stored in a root-readable-only file called /etc/shadow.)
There are systems where the user enters a key locally and it's not transmitted over the wire. Kerberos and SRP are two of them.
- blackflame7000 8y agoThis is the correct way to do it. I would say that a negotiated Salt isn't necessary and infact should be discouraged. Let the Server use its mystery SALT to make it impossible to use rainbow tables should the database get hacked.
- lucideer 8y ago> If the client could simply send a hashed password over as an authenticator, then hashing the password database would provide no protection against theft, because you could simply use the stored hash as the password. I'm not sure I understand this sentence. Are you reading the parent message as proposing hashing client-side using the same algorithm as the server-side hash and comparing directly on the server against the database-stored hash. This would be outrageously stupid of course, but I'm certain the commenter was not proposing that. They said: > hash on the client side first to avoid sending the password to the server, and then hash again on the server. Note, hashing again on the server. To describe this slightly differently, think of the clientside algorithm as effectively being a password generator, with the user inputting their own memorable password as a kind of encryption* key for their "real" auth API password—the main advantage is fighting password reuse. *encryption!=hashing but I'm just using the term here to illustrate intent.