18
$\begingroup$

I understand the theory behind the use salts in hash functions, but when I see it implemented, the implementations always generate the salt on the fly and the salt appears to be different for every hash.

  • When implementing a salt for users signing into a website, doesn't the salt need to be the same at account creation as the salt used when the user wants to log in?

  • In implementation, wouldn't the salt be the same every time?

  • I understand that the salt may be different from user to user (in my example), but when user A signs in on Monday, and again on Friday, wouldn't the salt need to be the same for both those times?

Improve this question
$\endgroup$

3 Answers 3

Reset to default
18
$\begingroup$

Usually, when the user registers, you will generate a random value to become the salt. Then, in the user database, you store the user's name, salt, and hash generated using the password and salt (and whatever else is relevant for a user table).

Note that doing it this way allows each user to have a unique salt. Each user having a unique salt greatly increases attack difficulty. An attacker is forced to do a brute-force attack per user instead of precomputing per-password-scheme rainbow tables (no salts) or a per-database rainbow table (a system-wide salt). It is still your responsibility to make sure the brute force attack is actually slow enough to be costly to an attacker in these days of massively parallel GPU hash implementations.

Ideally, an attacker would not even be able to see the salt on the database, but it does not have to be private if worse comes to worse.

Improve this answer
$\endgroup$
5
  • $\begingroup$ The only way an attacker would see the hash (ideally) is if they obtain a database dump. That dump would contain the salt... Don't you want to keep the two pretty far apart? Putting the salt right there with the hash is almost like storing decryptable data with half of the key used to encrypt it, in my opinion. $\endgroup$
    – Corey Ogburn
    Jul 12, 2011 at 20:01
  • 7
    $\begingroup$ That's not true. Without the salt, the attacker would be required to execute a brute force attack. With the salt, the attacker will still need a brute force attack. The difference is, with salt the attacker cannot pre-compute many easy hashes (of 'dog', 'password', etc.) but rather must re-compute the entire hash key space ('dog_kaskd2e','password_kaskd2e', etc). $\endgroup$
    – samoz
    Jul 12, 2011 at 20:10
  • $\begingroup$ You could also think of this as a first preimage attack. This attack is that given a hash h, find a message m where H(m) = h. If the salt was known, this would simply reduce to H(m | salt) = h. Assuming you have a secure hash algorithm, it should be able to resist this first preimage attack. $\endgroup$
    – samoz
    Jul 12, 2011 at 20:12
  • $\begingroup$ Ah, I see what you mean about not allowing attackers to use pre-computed easy hashes. After seeing so many Sony releases, I see where salt would have saved them from a lot of shame. I'll learn from their mistakes (and your answer/comments) $\endgroup$
    – Corey Ogburn
    Jul 12, 2011 at 20:39
  • 2
    $\begingroup$ Salts definitely don't need to be secret. If you don't know the motivations for using them, you might find this answer interesting stackoverflow.com/questions/2583203/salt-passwords-and-security/… $\endgroup$
    – ZoFreX
    Jul 13, 2011 at 10:48
10
$\begingroup$

Yes, you need to use the same salt each time you use a hash created with that salt. Typically a pseudorandom salt is generated for each user, and stored alongside the hash. Many hashing libraries (for example, bcrypt) create hashes with the salt embedded in them.

Improve this answer
$\endgroup$
5
$\begingroup$

At one past employer, we used some tables substantially like the following:
these are simplified

The web app would switch out different algorithms based on which hash algorithm was being used. And if the hash used for a particular customer was now obsolete, they would be required to change their password, and it would update their row in the user table with the new hash. For some reason the business dudes (aka "suits") would change their minds about what was acceptable for hashing, and micromanage all sorts of things (for example, "salt must be prepended to the password", which was later changed to "no! salt must be added at the end of the password") based on whatever blog post or bizjournal they read that week. This lead to there being any number of hashing algorithms in use per year. I think that was horrible overkill, and there should only be 1 algorithm in use at any time (and at most 2 when switching from "old" to "new").

Salts were generally generated when the user signs up for the first one. But when the suits decided on a new hashing algorithm, they sometimes required that the salt get changed.

When EULAs would change, we'd have to force the user to read the new one and agree to the new one, and keep track of who agreed to what.

disclaimer: I used this picture on a different post.

Improve this answer
$\endgroup$

Your Answer

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

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