19

Okay, I know this is probably dead simple, but I can't seem to find a straight answer anywhere. Let's say I have the following:

Password: "mypassword"
Salt: 1234567

Is the idea of salting to do something like hash(password + salt) or hash(password) + salt? My guess is that only the former makes any sense at all, but I just want to make sure I'm not missing something.

Please forgive my ignorance.

user456584
  • 86,427
  • 15
  • 75
  • 107

5 Answers5

21

You've got it, it's the former.

If you just concatenated the salt and the hash, then an attacker can simply remove the "salt" and use a rainbow table. By hashing the plaintext + salt, the salt cannot be factored out.

John Cromartie
  • 4,184
  • 27
  • 32
12

Actually, it's salt + hash(salt+password) (Salt is part of the hash computation - but you must also keep it in the clear)

leonbloy
  • 73,180
  • 20
  • 142
  • 190
8

hash(password + salt). If you concatenate the salt after the hashing, the concatenation is easily reversible and doesn't add any difficulty in reversing the hash on the password (with rainbow tables).

That said, some systems do both, e.g. Django stores salt$hash(salt+password) in database. This is simply so that every piece of data needed to check the password against the hash is available in one place.

Igor Nazarenko
  • 2,184
  • 13
  • 10
3

I'm adding these links into this question for completeness - this topic of salty hashing requires a broad understanding of the topics feeding into it to avoid costly mistakes.

A key point not quite expressed in the answers here is the necessity of using a unique salt for each password. For details on why, read the linked items.

Why make each salt unique : Salting Your Password: Best Practices?

Broad overview on the topic : Salt Generation and open source software

Community
  • 1
  • 1
Gavin C
  • 88
  • 5
0

The salt should be part of the hash calculation

Robert
  • 21,110
  • 9
  • 55
  • 65