6

Lets set out a scenario, a database has been dumped and all the passwords are hashed.

You notice that some users seemed to have signed up twice and have the same hash. You run these hashes through your hash cracking program and nothing comes up, presumably because they are salted and you don't have the salt. But because users have the same hash on 2 accounts the salt isn't going to involve any random values, correct?

If the site was still vulnerable and you were able to create your own account and retrieve your own hash would you be able to reverse-engineer the salt given you know the password you signed up with?

||improve this question
  • 1
    ideally salt should be a part of your db dump.. – Shurmajee Oct 15 '13 at 17:05
  • 1
    Salt won't be part of the DB if it's done in code though surely? – user32045 Oct 15 '13 at 17:07
  • Then it's not a salt. The entire purpose of a salt is to be unique. – Stephen Touset Oct 15 '13 at 17:30
  • 1
    Well no, technically not but Devs's seem to think so. – user32045 Oct 15 '13 at 17:39
7

Disregarding collisions, two users having the same hash value means that both of them have the same password, salt, and pepper. Consequently, this usually means one of two things

  1. The site uses a fixed salt for all users: This renders the scheme to a pepper-only password hashing scheme (the "salt" is in the code). By means of brute force, and by employing knowledge of a plaintext password, you can find out the value of said "salt".

    This, of course, can be done by registering another account of your choice and attempting to brute-froce something like hash(password + X), with X being the value you want to find out, and then comparing the output to the hash you extracted after creating your new account.

    A site doing something as stupid as using a hardcoded salt (pepper-only) will probably be using something like MD5 or SHA-1, which will make your brute-force attack much faster.

  2. The site uses non-unique salts derived from certain information from the user: (username, email, etc.) which you can find out by means of brute-force.

Since the database you extracted didn't contain any salts, it is most likely the case #1.

Note: Just because a duplicate hash wasn't found in rainbow tables, that doesn't mean it's an easy password. It might be the same user with two accounts using the same strong password.

||improve this answer
  • @user32045 I'm glad you found that helpful, but I'd wait just a couple of hours before accepting my answer, as other answers might be posted and you might find them more helpful. – Adi Oct 15 '13 at 17:24
  • 3
    Actually I think case #1 is still quite plausible: some sites use as "salt" the user's email address. It is part of the database, but you usually don't look at it and think "mmh, this is a salt". This would explain why the same user, registered twice, gets the same hash. This can be tested for by registering a few accounts, with the same password but distinct names and distinct email addresses. – Tom Leek Oct 15 '13 at 18:05
  • @TomLeek Indeed. I haven't looked at it from this angle. – Adi Oct 15 '13 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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