Take the 2-minute tour ×

I want to update my password setup that is currently using just MD5.

Now what I would like to do is use something stronger (maybe sha256) with unique salt per user.

The question is about the salt storage.

Do I go with storing the salt in its own column in the database?

Then hash salt + password and when it comes to login, call the salt and password from the database, to make one.

Or do I go the way of making a salt, by using the username, email and timestamp which would also give me a unique salt per user?

I am wondering, if someone got a hold of the database with salt as a column, they would know the salt for each user, then they could crack the password.

share|improve this question
add comment

3 Answers

Just reading on another post and someone says the salt is not a secret and can be stored a database column. So that answers my question

share|improve this answer
add comment

The salt is not a secret, it can be stored plaintext together with the hash. It is not even necessary to have a second field in the database. If you look at PHP's crypt() function, you can see, that the salt will be included in the hash value itself.

It's the job of the salt, to make already existing rainbowtables useless, because a rainbowtable has to be built for one specific salt. Using a different salt for every hash will prevent rainbowtable attacks, because you would have to create a rainbowtable for each hash. That's why it is not necessary to keep the salt secret.

I would recommend, that if you want to improve your password hash system anyway, you do it right, with a hash function that is slow. The article password hashes with bcrypt explains the important points of generating a hash for passwords.

  • Generate a salt per password, not per user.
  • Use a random (unique) salt, not one derrived from other parameters.
  • Use a slow hash function.

Last but not least, don't be afraid of doing it correctly, the code of your application can be as easy as your current implementation with MD5.

share|improve this answer
How can salt not be secret? If attacker knows the salt, he can easily modify the dictionary attack to include the salt and voila! –  Mārtiņš Briedis May 25 '12 at 11:25
@Martins Briedis - Precalculating all hashes of a certain dictionary is usually called a rainbow table. An attacker could not use already existing public rainbowtables (just googling for the hashed value), because a rainbowtable has to be made exactly for one specific salt (or for the original dictionary if no salt was used). –  martinstoeckli May 25 '12 at 11:31
@Martins Briedis - Forgot to mention, that building a rainbow table is not a task you do in a few seconds. When you use a slow hash function (like bcrypt) it needs a lot of time, and if you use a different salt for every password, then you need a lot of time for each password. –  martinstoeckli May 25 '12 at 11:42
it's better to keep it secret... –  chumkiu May 25 '12 at 12:35
@chumkiu - Why, and where would you store the key? –  martinstoeckli May 25 '12 at 12:49
show 6 more comments

Forget MD5 or SHA. Use Bcrypt. (Blow Fish Crypt) Comes native with PHP 5.3 and above. (crypt method 2a) it is more secure and processes slower.

When using Bcrypt the salt is stored together with the hash in the same feild . There is no reason for a seperate one.


share|improve this answer
So would phpass - openwall.com/phpass do the job? –  Garry May 25 '12 at 13:33
Yes PHPass would work. I recommend just using the native php functions above tho if using php 5.3 above –  Ray May 25 '12 at 14:53
add comment

Your Answer


