18

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?

Paŭlo Ebermann
  • 22,946
  • 7
  • 82
  • 119
Corey Ogburn
  • 851
  • 7
  • 18

3 Answers3

18

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.

joeforker
  • 571
  • 5
  • 13
foobarfuzzbizz
  • 3,256
  • 3
  • 24
  • 25
10

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.

ZoFreX
  • 269
  • 2
  • 4
5

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.

Community
  • 1
Tangurena
  • 1,436
  • 15
  • 21