CODEWITHSUNDEEP
phpsecuritypasswordssalt-cryptography
steeped
steeped

Reputation: 2633

How should I store a password salt?

Using PHP, I am encoding passwords using the hmac function with the sha256 algorithm. What I'm not sure about is how to properly store the salt.

The whole point of hashing a password is in case a hacker gets access to the database. If I store the salt in the db within the same row as the hashed password, isn't it just like I am handing the hacker the "secret code"? I am putting up a door with a lock, and handing the intruder the key.

Can anyone please explain to me how they come about storing their salt?

Upvotes: 12

Views: 1049

Answers (3)

tereško
tereško

Reputation: 58444

I would opt for storing salt along with hashing algorithm's identifier and the hash itself.

Here is why:

Usually the the access to database is limited to localhost or some predefined range of IP addresses. Which means that, for a hacker to gain access to your database, he/she would need to compromise your servers filesystem (either by gaining direct access or injecting a script). Or perform an SQL injection.

In the former case it would mean, that if someone gained access to your salts in DB, he/she could as easily read them from your PHP files source.

The latter cause can be simply prevented by use of prepared statements with either PDO or MySQLi. You shouldn't be using the old mysql_* functions as API anymore. They are not maintained anymore and the process of deprecation has begun already.

Even if someone gets his/her hands on your DB, it is not all that problematic. If you are using crypt() function for creating hashes with good algorithms (recommended would be CRYPT_BLOWFISH), then cracking even a single password can be exceedingly long (in the scale of years). By that time you can easily send out "change your password" notifications to users, and lock all the ones, who have not done so.

If you are using PHP 5.5+, you should instead be using the new password API: http://php.net/password

Upvotes: 3

Jé Queue
Jé Queue

Reputation: 10653

The salt is intended to be as cleartext and immediately available. A password hash is perfectly non-reversible, but it is dictionary attackable. As such, salt enough to add a few orders of magnitude to perturb the dictionary attack. Making the salt available should not degrade the security of the hashed password.

Upvotes: 2

Michael Berkowski
Michael Berkowski

Reputation: 270599

Putting the salt into the hands of an attacker who has stolen your database isn't actually a problem. Combining the salt with the original password into the password hash protects against the attacker using "rainbow tables" of millions of known and well-known password hashes to obtain the passwords of some of the stolen user ids.

Having hashed the password and salt together makes it many orders of magnitude more difficult to crack even a single password, on the basis that the salt invalidates the password hashes known in the rainbow table. So even if the salt is known by the attacker for each of your users, this means that in order to crack any single user, the attacker must compute a whole new rainbow table just for that user alone, which combines the user's salt with the rest of the passwords known in the rainbow table they started with.

Salting the password does not make it impossible to crack a password, but far more difficult. An attacker could, for example, target a small subset of your users with the hash and salt in hand, and that's another reason to encourage strong passwords which are less likely to appear in a rainbow table.

Upvotes: 16

Related Questions