How do I implement salt into my login for password

Question

I want to implement a salt into my login system but am a bit confused on how this is supposed to work. I can't understand the logic behind it. I understand md5 is a one-way algorithm and all of the functions that I have come across seem to hash everything together. If this is the case, how does one get the password back out for comparison? My biggest question is, how is salting a users' password safer than just hashing the password? If a database was ever to be compromised, the hash along with the salt is in the database. Isn't this all that a hacker would need?

I also found another post here on SO where another developer said :

"Ensure your salt and algorithm are stored separately from the database"

I would like to store the salt in the database. Is this really a problem if I do?

I'm looking for some help on understanding how this works and also what the best practice might be. Any help is greatly appreciated.

---

EDIT: I want to thank everyone for their responses and ideas. Even though I may be more confused now, it has certainly been a learning experience for me. Thanks again guys.

Answer 1

You don't get the password out for comparison. You encrypt the password when they attempt a login and compare the stored value with the newly encrypted value.

Answer 2

The point of a salt is to prevent attackers from amortizing the cost of a brute force attack across sites (or better yet, when using a different salt for each user: all users of a site) through precomputed rainbow tables.

With plain hashing, an attacker can compute such a table once (a very long, costly operation) and then use it to quickly find passwords for any site. When a site uses one fixed salt, the attacker has to compute a new table specifically for that site. When a site uses a different salt for each user, the attacker can stop bothering with rainbow tables - he'll have to brute-force each single password separately.

Storing the salts separately is not necessary to gain this advantage. In theory it would be even more secure because it would neutralize the weakness of dictionary or short passwords. In practice, it's not worth bothering with because at the end of the day, you need access to the salts somewhere to check passwords. Also, trying to separate them would lead to more complex systems - and the more complex a system is, the more opportunities for security holes there are.

Edit: My concrete recommendations:

• Generate long pseudorandom salt for each user and store in in the DB
• Use a bcrypt-based hash
• ideally, don't implement it yourself, use an existing library instead

Answer 3

Hashing passwords is meant to keep those passwords secret from your own administrator(s).

1) Keeping plain text passwords in your database would be fine except your passwords may be used by the administrator to gain access to some other system.

2) You can use a single global salt, which is combined with the passwords (by prepending or XORing them) and then hashing for storage in the database. But that is vulnerable to a malicious administrator AND a rainbow table designed for that one salt.

3) You can have a separate salt for each user: The database will be used to store the salt, and the hash derived from the password/salt combination. This will prevent a rainbow attack, but brute force attacks will still be possible.

4) Finally, you can keep your hash function a secret by using a velocity-limited hardware hashing solution.

That is as good as you can do. Because of human nature, passwords have a limited domain and are vulnerable to brute force attacks. We are trying to prevent administrators getting a hold of user passwords, and then using them on other systems they should not have access to.

Some other notes:

a) You can use bcrypt on the password/salt combination to slow down the attacker’s brute force attack. But since we are assuming administrators, they can be patient.

b) Keeping the salt separate from the password hash is not an effective defense, we are assuming administrators after all.

c) Using existing data as a salt is a little better, but I doubt existing data has as much entropy a random salt has.

Answer 4

Forget about using salts (partly for the reason you mention), use bcrypt instead:

For a good explanation see: http://codahale.com/how-to-safely-store-a-password/

Answer 5

The other answers are good, so I'll just throw in a minor point that nobody else has mentioned. You don't want to use the same salt for every password because then if two people have the same password, they'll have the same hash. That's exposing information that an attacker can exploit.

You could use the same salt for every user along with Juraj's good idea to combine the password with other non-changing database fields (unique to a user). But watch out because this information gets tied to the password. If you were to hash the username + password together to guarantee a unique hash, you wouldn't be able to change the username without creating a new user and requiring them to set a new password.

As an example of having a unique salt per user and storing it alongside the password hash, I'll point out /etc/shadow on your typical Linux system.

root@linux:/root# cat /etc/shadow | grep root
root:$1$oL5TTZxL$RhfGUZSbFwQN6jnX5D.Ck/:12139:0:99999:7:::

Here, the oL5TTZxL is the salt and RhfGUZSbFwQN6jnX5D.Ck/ is the hash. The plain-text password is root in this case, and the hash algorithm my system uses is the MD5-based BSD password algorithm. (newer systems than mine have better hash algorithms)

Answer 6

As you mentioned, hashing algorithms work only one-way (or only if they are strong enough :-D)

For your question about salting I would recommend to hash a password with a static salt string and some dynamic data from database, which should not change after once created

This is a very secure way of storing passwords, as even if database is compromised, hackers/crackers still need to get your static string hash and need to guess how you applied all the salting..

For example let's say you have a users table with these columns:

id
username
password
created_at

columns id and created_at after once filled should never be changed..

so when you are hashing user's password you can do as simple as:

<?php
    $staticSalt = '!241@kadl;ap][';
    $userPass = 'my new pass';
    // assuming $user variable is already populated with DB data
    // we will generate new hash from columns and static salt:
    $genPass = sha1($user['id'] . $userPass . $user['created_at'] . $staticSalt);
?>

I hope this one helps :) cheers