Categories
password-hash php php-password-hash salt

How to use PHP’s password_hash to hash and verify passwords

129

Recently I have been trying to implement my own security on a log in script I stumbled upon on the internet. After struggling of trying to learn how to make my own script to generate a salt for each user, I stumbled upon password_hash.

From what I understand (based off of the reading on this page), salt is already generated in the row when you use password_hash. Is this true?

Another question I had was, wouldn’t it be smart to have 2 salts? One directly in the file and one in the DB? That way, if someone compromises your salt in the DB, you still have the one directly in the file? I read on here that storing salts is never a smart idea, but it always confused me what people meant by that.

2

  • 9

    No. Let the function take care of the salt. Double salting will cause you trouble and there’s no need for it.

    May 16, 2015 at 18:43

  • As @martinstoeckli mentions in their answer, what’s being described here is known as a “pepper” and is often recommended these days. You were a trailblazer, Josh! 😀

    – JoLoCo

    Feb 3 at 17:55

237

Using password_hash is the recommended way to store passwords. Don’t separate them to DB and files.

Let’s say we have the following input:

$password = $_POST['password'];

You first hash the password by doing this:

$hashed_password = password_hash($password, PASSWORD_DEFAULT);

Then see the output:

var_dump($hashed_password);

As you can see it’s hashed. (I assume you did those steps).

Now you store this hashed password in your database, ensuring your password column is large enough to hold the hashed value (at least 60 characters or longer). When a user asks to log them in, you check the password input with this hash value in the database, by doing this:

// Query the database for username and password
// ...

if(password_verify($password, $hashed_password)) {
    // If the password inputs matched the hashed password in the database
    // Do something, you know... log them in.
} 

// Else, Redirect them back to the login page.

Official Reference

7

  • 4

    Ok, I just tried this and it worked. I doubted the function because it seemed almost too easy. How long do you recommend I make the length of my varchar? 225?

    May 16, 2015 at 19:11


  • 4

    This is already in the manuals php.net/manual/en/function.password-hash.phpphp.net/manual/en/function.password-verify.php that the OP probably didn’t read or understood. This question’s been asked more often than none.

    May 16, 2015 at 19:16

  • 14

    @FunkFortyNiner, b/c Josh asked the question, I found it, 2 years later, and it helped me. That’s the point of SO. That manual is about as clear as mud.

    – toddmo

    Apr 23, 2018 at 1:22

  • 1

    As for the length, from the PHP manual on password_hash, there’s a comment in an example — “Beware that DEFAULT may change over time, so you would want to prepare by allowing your storage to expand past 60 characters (255 would be good)”

    – Sheamus

    Jun 6, 2020 at 3:37

  • 1

    @toddmo : To second your comment, I’ve just come to this question in June 2020 and the discussion has saved me hours of frustration. I, too, find the PHP manual about as clear as mud most of the time.

    Jun 10, 2020 at 12:25

30

Yes you understood it correctly, the function password_hash() will generate a salt on its own, and includes it in the resulting hash-value. Storing the salt in the database is absolutely correct, it does its job even if known.

// Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($_POST['password'], PASSWORD_DEFAULT);

// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($_POST['password'], $existingHashFromDb);

The second salt you mentioned (the one stored in a file), is actually a pepper or a server side key. If you add it before hashing (like the salt), then you add a pepper. There is a better way though, you could first calculate the hash, and afterwards encrypt (two-way) the hash with a server-side key. This gives you the possibility to change the key when necessary.

In contrast to the salt, this key should be kept secret. People often mix it up and try to hide the salt, but it is better to let the salt do its job and add the secret with a key.

    8

    Yes, it’s true. Why do you doubt the php faq on the function? 🙂

    The result of running password_hash() has has four parts:

    1. the algorithm used
    2. parameters
    3. salt
    4. actual password hash

    So as you can see, the hash is a part of it.

    Sure, you could have an additional salt for an added layer of security, but I honestly think that’s overkill in a regular php application. The default bcrypt algorithm is good, and the optional blowfish one is arguably even better.

    1

    • 2

      BCrypt is a hashing function, while Blowfish is an algorithm for encryption. BCrypt originates from the Blowfish algorithm though.

      May 16, 2015 at 18:43