Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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. – bmm6o Jun 26 '14 at 16:11
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. – user9070 May 4 at 12:38
up vote 5 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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