Letting the client know the salt and/or calculating the hash client side is effectively the same as not hashing your database at all. Your server side authentication just becomes comparing the string the client sends with what you have stored in the database, with no processing. Anyone with access to your database then has everything they need to authenticate as any user. The point of hashing passwords is that even if you do have direct access to the database, you shouldn't be able to authenticate as any user. On July 16, 2020 12:50:36 AM PDT, Frank Ebner <ebner@xxxxxxxxxxxxxx> wrote: > >When the salt is generated automatically: > >- The plain text password must be known to PHP every time >authentication is performed. This is by design. Anyone with knowledge of the hash still needs to know the password to authenticate. If you're just comparing hashes to hashes, then effectively the hash is the password and you're not getting any security benefit. >That is, it has to be sent from the Client to the Server. >While HTTPS mitigates the problem, a man-in-the-middle attack can >capture the plaintext password. No, HTTPS, properly implemented, _solves_ this problem. If you're using https, you are protected from MITM (assuming that clients are properly handling certificates, but that's a concern for any security measure). >- password_verify() must be used to check the plaintext password, >adding load to the Server, >requiring explicit DOS protection. This is true for anything your server does. Not hashing passwords correctly does not protect you from DOS. >When manual salts are allowed: > >- Client and Server could e.g. agree to use "username + (static) random >data" as salt. This is not salting. This is changing the password. The difference is not just semantic. Salting is ONLY effective if done server side. >While the password hashes themselves are less secure, >this allows for authentication procedures based on comparing a >calculated with a stored hash, >not requiring plaintext password transmits, and reducing server load. The password hashes in this scenario are not any more secure than if you were just storing your passwords in plain text on the database. In this setup, anyone who somehow intercepts the hash (by a phishing scam for example) now has full access to the account. When hashing/salting properly, you can have the hash, but you still need to know the password and salt to authenticate. The user knows the hash and you (or rather your database) know the salt. Nobody has enough knowledge to impersonate a user.
