4
$\begingroup$

I was researching about hash, and I thought, If sites store passwords with hash algorithms, then can't this happen:

  1. User A has the password 'hello'
  2. User B finds out the hash code of the password of user A
  3. User B knows the username of user A and uses hash collision to find a string with an identical hash
  4. User B logs in the account of user A

So now, my main question is: Do databases store the hash of the password or not? And if they do so, can the thing I wrote above happen?

$\endgroup$
2
  • 1
    $\begingroup$ It can happen but don't underestimate the effort of step 3. Also it's better than the alternatives. Storing plaintext means that B is done at step 2. Storing encrypted passwords means B just needs the key, which is stored in process memory. $\endgroup$
    – bmm6o
    Commented Jun 26, 2014 at 16:11
  • 1
    $\begingroup$ Yes, there will be multiple passwords that allow a user to login. But length and character set restrictions might mean there are few collisions in practice. $\endgroup$
    – user9070
    Commented May 4, 2016 at 12:38

3 Answers 3

5
$\begingroup$

Databases generally store hashed passwords (as they should), but some store it plaintext. If someone were to find a hash collision that matched the stored, unsalted, and hashed password, then yes, they would be able to use that collision to login, because the client would send the password to the server, the server would calculate the hash and compare it to the one in the database. Since the two match (different input, same hashed value), login would succeed. However, I might like to add, it's more computationally feasible that one would bruteforce the password as opposed to finding a collision, especially with the generally small size of a password.

$\endgroup$
3
$\begingroup$

Best practice is to use a slow hashing function like PBKDF2 or Scrypt as brute-forcing the hash of a typical password is trivial. The resulting hash is stored in the database. When a user logs in, their password is fed through the aforementioned function and the output compared with the hash stored in the database. Assuming a salt is used, the work factor is sufficient, and the output is sufficiently long (say 256 bits), no collisions should occur, and brute-forcing becomes infeasible.

$\endgroup$
1
$\begingroup$

Do databases store the hash of the password or not?

Yes, they do.

And if they do so, can the thing I wrote above happen?

Perhaps it could, but it's unlikely. It is usually easier to find the original password rather than a collision. With a strong hash function, it is difficult to find another string with the same hash as the string 'hello', but easy to quickly verify whether the hash really matches 'hello'.

Even strong key-derivation functions have to use few enough rounds to handle a number of users (on the server), so they would usually allow an attacker to make tens to thousands of guesses per second. When a salt is used, each user's hash has to be attacked individually. Nevertheless, if the password is e.g. on a list of top 1000 passwords (which can be over 90% of them), like 'hello' is, it will fall in a matter of seconds.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.