0

A large number of posts I've seen, regarding password hashing, says something along the lines of:

  1. Use a globally unique salt for each password
  2. Store salts in DB, alongside the hashed password

Dare I even say that this is the most common approach outlined?

It all makes sense - if you needed to rehash the input password each time - but in PHP you can use crypt to verify a password, without ever using the salt. According to this post, it is "how it should be done".

For example: 

$pass = 'YoiI8SjPAlFj';
$salt = '$2y$09$959d78f2f983628c711c7d'; 

echo $hashed = crypt($pass, $salt);

// $2y$09$959d78f2f983628c711c7O3YM7Xdl8Gdnh.S0C.ak41wA8RI1/3ga

And then to verify (using same vars)...

if(crypt($pass, $hashed) === $hashed) {
    // Success
}else {
    // Fail
}

Which will pass, just fine.

If that's the case, then why would I need to store the salt with my password? If the user changes their password, I'll generate a new salt anyway. It seems to me that the salt is superfluous information to store, and just takes-up memory.

Are there any arguments FOR storing it? 'Cause I can't think of any.

Community
  • 1
  • 1
Birrel
  • 4,754
  • 6
  • 38
  • 74
  • 2
    You ***need*** the salt if you ever want to recreate and thereby validate the hash. And in fact you are already storing the salt as part of the hash. – deceze Nov 16 '16 at 10:14
  • @deceze the link you pointed to is a good explanation. Is there any benefit to removing the salt from the hashed output, and storing the two separately in the same DB? – Birrel Nov 16 '16 at 10:16
  • 2
    Erm… more work, more complications? – deceze Nov 16 '16 at 10:17
  • Good enough. Thanks for your input. Too many spook stories about nefarious hackers; it makes approaching security ungodly daunting for us new players. – Birrel Nov 16 '16 at 10:19
  • 1
    Really, you should be using PHP's `password_hash` API, which was specifically created to simplify all this a bit and give you less rope to hang yourself with. – deceze Nov 16 '16 at 10:20

0 Answers0