How do websites check that password hashes saved in the database are the same as passwords hashed and sent by a client?
I know that client-side hashing is not secure.
-
2Do you mean, hashes are computed on the client side and sent for comparison to the server? This is not what password hashing is used for. Is your question "How password hashing works?" Or is your question "How can authentication work without sending the password to the server?"– mentallurgCommented Apr 4, 2023 at 7:47
-
If you actually meant client-side hashing, then the answer you accepted is wrong because it isn't about "sending a hash to a server". Can you clarify what you actually mean?– schroeder ♦Commented Apr 6, 2023 at 11:31
Add a comment
|
3 Answers
Suppose when the user registers with the site, he creates an account with username: user and password: p4$$w0rd. The server generates a random salt, then passes the password and the salt to a password hashing function (such as PBKDF2, Argon2, etc). Let's call the output of the password hashing function H. The salt and H are stored in the database record for user.
Later, the user comes back to the site, and attempts to login using the username: user and password: p4$$w0rd. The server queries the database record for user, to get the salt and H for that user. The server passes the password (p4$$w0rd) and the salt to the password hashing function, and compares the result of this with H. If they match, then the user is authenticated.
-
The OP is asking about client-side hashing, though ("send hash to the server").– schroeder ♦Commented Apr 4, 2023 at 7:35
User enters name and password. Browser sends them to the server. Server looks up for an entry by user name. From the found entry server takes the salt and other parameters (depending on hashing methods, these can be number of iterations, memory factor) and calculates a hash of password using the same parameters. Then compares the result with the hash in the database.
send hash to the server, which is not secure
A secure connections should be used, means HTTPS/TLS. If connection is not secure, then of course sending any authentication data is not secure.
answered Apr 3, 2023 at 23:57
-
The OP is asking about client-side hashing, though ("send hash to the server").– schroeder ♦Commented Apr 4, 2023 at 7:33
-
@schroeder: If you understand the question literally, you should close it, because nobody is sending hashes from the client to the server. I think we should help to understand how the authentication works. Where as you suggest to formally answer the questions even if the wording in the question may be incorrect, because of lack of understanding how it works. I find such approach not helpful. Commented Apr 4, 2023 at 7:43
-
"nobody is sending hashes from the client to the server" -- not true.– schroeder ♦Commented Apr 4, 2023 at 7:45
-
You've answered a question that wasn't asked. That's all. If you want to guide the OP to a better solution, even though the OP has stated that they understand that the use case is problematic, that's fine, as a comment, but your answer misses the mark.– schroeder ♦Commented Apr 4, 2023 at 7:46
-
@schroeder I respectfully disagree. The question that OP posed before it was edited was 'How websites cheks that hashes of entered and saved in data base password the same?'. He is asking how the server validates the password entered by the user against the hashed password stored in the database. He ponders client-side hashing (i.e. 'In this case you need send hash to the server''), but rules this out as a solution ('which is not secure').– mti2935Commented Apr 4, 2023 at 11:20
If the passwords are hashed client-side and the hash is sent to the server and the server isn't supposed to do anything with the hash, then the comparison process would be the same as if the password is sent and not hashed client-side. The hash string is simply looked up in the server's authentication database. This is generally seen as a bad implementation and is not recommended. Old websites or custom-built sites and applications that did not follow modern best-practice may still do this.
Some modern implementations hash client-side, but the server also salts and hashes the submitted hash and treats the client-side hash like a password. In this case, the process is the same for a plain password. The hash becomes the password, and the hash string is treated like any password string in a modern "salt-hash-store/compare" logic flow.
Note that salting on the client-side is very difficult, and usually not done. So, that's not something that needs to be managed or accounted for on the server side, unless you are talking about a custom implementation.
answered Apr 4, 2023 at 8:19
