What should be used as a salt?

Question

I always hear that it is best to use salts on top of stored passwords, which then somehow gets concatenated and hashed afterwards. But I don't know what to use as a the salt. What would be a good salt?

Answer 1

The classical recommendation for a salt for password hashing is:

• A random value of 128 bits or more;
• obtained from a cryptographically sound random number generator (/dev/random or /dev/urandom on modern day Unixes);
• unique for each entry (i.e. don't re-use the same salt, generate a new salt for each new password);
• stored in plaintext in the database (so that the salt is available when verifying the hash).

There are plenty of past discussions of related topics. And most importantly, you should not implement your own password hashing scheme -- you should use a proven, well tested, peer reviewed implementation (bcrypt/PBKDF2).

Answer 2

Let's say that you have a table where you'll store the password for each person.

To "save" the password that's being generated, do the following

1. get the login from the user
2. get the password
3. generate some salt from random values. Let's say, from /dev/random (as @Michal suggested), you got "a12bc34de56fg"
4. Use some hashing function to generate the hashed password. Let's say the original password was "1password" and you'll use any SHA hashing. You'll do

hashed_password = SHA(SHA(SHA(.... SHA("1passworda12bc34de56fg"))))))))

Store that hashed_password, with the login and the salt, in the table.

login      password      salt
--------------------------------------
john       a7b82783...   a12bc34de56fg

And then, to verify when a user access your app:

1. get the login and the password
2. retrieve the salt for that login from the database (you'll have the salt: a12bc34de56fg)
3. concatenate the plain-text-password with the salt and do all the hashing again:

hashed_password = SHA(SHA(SHA(.... SHA("1passworda12bc34de56fg"))))))))

Verify if the hashed_password that you calculated is the same that was stored in the database. You'll know if the password was correct or not.

That's it!. You can get the salt from any random source you like. Why should it be random? Because any non-random salt would make it much easier to to attempt to brute-force your app.

Answer 3

The answer is "almost anything", although some are stronger than others.

Let's assume you are using md5(salt.password).

With no salt, hackers will quickly crack most of the passwords just by looking up the hash in a rainbow table.

Let's say you use "x" as the salt for all your passwords. Many of your passwords will still be found, but fewer. That's because if the password is "p4ssw0rd", then it becomes "xp4ssw0rd" with the salt -- making it slightly harder, but not significantly so.

Now let's say you use "%X88Fc+7" as the one salt for all your passwords. At this point, rainbow tables aren't going to work. But, the consequence of using one salt for all passwords, the hacker will be able to generate a rainbow table with that assumption, and built rainbow tables ahead of time. It's a lot more secure, but not perfect.

The next most secure option is to use the username as the salt, in other words using 'md5(username.password)'. Again, this defeats the standard rainbow table, but a hacker might generate a rainbow table for a specific username (like "root" or "administrator"), so that every time the password is changed, the hacker can do a looking in a rainbow table instead of cracking it again.

So, to be even more secure, choose a different random salt for different users. You have to store this along with the username and password hash. This completely defeats rainbow tables.

Some suggest a "secure" random number generator, rather than something simple. For example, doing an MD5(timestamp+username) when the user creates an account is simple, but not cryptographically secure (since timestamps and usernames are predictable, and thus low entropy). But, since the hacker has a copy of the salt anyway when he steals the database, it's not a problem.

Answer 4

For salt just use random bits.

On Linux you can use /dev/urandom. It is a random number generator based on environmental noise. It's quite unpredictable except for virtual machines. So if you have let's say physical mouse plugged to your box, then /dev/urandom will give you high quality random bits and is good for salt.

Here is a good article to start with. See also the external references.

Here is an example java code. See how the salt is generated and stored in DB in the createUser() function. Except for using import sun.misc. ... it's very good code.