Answer the question
In order to leave comments, you need to log in
Is stealing a password hash from an account database the same as knowing the password?
Consider the case of using a salted hash from a password.
Obviously, after the user created an account, a record about him was created in the database, and not the password itself will be stored on the server, but a salted hash from the user's password, for example, in the following format: salt:hash
Let, H () is the hash function to use. Then the value of the salted hash is: hash = H(password + salt)
How is the password checked? Depends on the specific implementation of the authentication protocol, but if the challenge-response authentication method is used, then the process is simplified as follows (for example, assume that the user login is login1, and the value of the salted hash is: salt1:hash1):
1. The client sends a pair to the server: (login1, random), where random is a pseudo-random number, each time a new number.
2. In response, the server sends a salt value.
3. The client calculates client_side_hash = H(random, H(password + salt)) and sends it to the server.
4. The server does not know the user's password, but it knows the value of the salted hash from this password, in our example it is salt1:hash1.
so the server calculates the hash like this: server_side_hash = H(random, hash1) and
5. The server compares client_side_hash and server_side_hash. If they match, authentication is successful.
Let's say an attacker via SQLi received a login1:salt1:hash1 entry from the account database.
Why would he brute force a salted hash password? Only if the attacker assumes that the password is being used by the user in other web applications as well.
Knowing salt1:hash1 is enough to successfully authenticate with this web application! Or I'm wrong?
Answer the question
In order to leave comments, you need to log in
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question