0

I've seen in some cases developers that use the encryption key, from the config.php, to hash passwords and store them in database. I was wondering is it better to do it this way, or better by creating a random salt (for example in a function) each time?

Well I guess in the first case you don't have to store (and) the salt in the database, but is it secure enough and what if there's a match with passwords?

ltdev
  • 4,037
  • 20
  • 69
  • 129
  • 1
    take a look at [this excellent answer](http://stackoverflow.com/questions/536584/non-random-salt-for-password-hashes/536756#536756) to another question why you should use randomly generated salts – Arash Milani Jun 02 '13 at 07:52

3 Answers3

3

You use salts to prevent an attacker's brute force attack to amortize across a whole database of hashed passwords. With a unique salt per password, even identical passwords will hash to different hashes, hence forcing an attacker to brute force every single password individually. By using a static salt, which is actually called a pepper to distinguish it from a real salt, identical passwords hash to the same hash, hence allowing an attacker to brute force a large set of password hashes much faster (you wouldn't believe how many people use "monkey" as their password).

Therefore:

  • unique salt per password is a must
  • optional pepper per password is a slightly added bonus, but only useful if you can keep the pepper secret from an attacker
deceze
  • 510,633
  • 85
  • 743
  • 889
0

It is true that randomly generated salts produce a greater amount of security, but it is also true that anyone who gets access to a list of your password hashes in order to crack them probably has access to your database, in which case they have access to your salts.

Glitch Desire
  • 14,632
  • 7
  • 43
  • 55
  • 1
    What if i use 2 salts then?? one stored in my database and the second one the encryption_key – ltdev Jun 02 '13 at 08:44
  • 2
    Salts are not meant to be secret in any way! – deceze Jun 02 '13 at 08:57
  • @deceze - Of course they are, an unknown salt makes bruteforce decryption against a hash impractical. A known salt just makes it more time consuming. – Glitch Desire Jun 02 '13 at 09:10
  • Keeping *unique salts per password* secret is impractical. Your application needs the salt, and since the salt needs to be stored with each password individually, if an attacker has access to one he likely also has access to the other. Using *one static secret pepper* is *worse* security than using individual unique "public" salts! Also see http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190. – deceze Jun 02 '13 at 09:19
  • *Time consuming* is exactly what you're going for here. If you use *one static secret*, it only needs to be broken once. Using individual unique salts, each hash has to be broken individually. If each hash takes long enough to break individually (because you're using a time consuming hash like bcrypt or scrypt), breaking an entire database of hashes becomes entirely infeasible. – deceze Jun 02 '13 at 09:22
  • I tend to use both a static and random secret, but that's just my security paranoia. I'd definitely rather require a database and frontend breakin to essentially dump my users' data than just a database breakin. – Glitch Desire Jun 02 '13 at 10:04
  • I agree with deceze, a salt is no more secret than the hash itself, and should just be kept with the hash. Thats exactly how it is done with bcrypt. – jah Jun 03 '13 at 01:49
-3

instead of using anything huge thing for hashing passwords, do use MD5 with salting and everythi

TheCodePress
  • 1