Question

I’ve been reading around a few different guides/tutorials on this topic and found the following:

• Storing Passwords Securely using Salt in PHP

• Secure Hash and Salt for PHP Passwords (Top Answer)

I know that what I’ve read there is a very secure way to store a users password. I’ve made an attempt to combined the 2 slightly while instead of using mt_rand like in the first example, I’ve generated my own dynamic salt.

Here is my code:

<?php

    $static_salt = ""; // Removed value for obvious reasons

    $dynamic_salt_choice = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
    $dynamic_salt_length = 40;

    $dynamic_salt = "";

    $dynamic_salt_max = strlen($dynamic_salt_choice)-1;

    for ($i = 0; $i < $dynamic_salt_length; $i++) {

        $dynamic_salt .= substr($dynamic_salt_choice, rand(0, $dynamic_salt_max), 1);

    }

    $password_length = length($password);
    $split_at = $password_length / 2;
    $password_array = str_split($password, $split_at);

    $password = $password_array[0] . $static_salt . $password_array[1];

    $password_hash = hash_hmac('sha512', $password, $dynamic_salt);

?>

According to me this is fetching a static salt, generating a dynamic salt, we’re then splitting the given password in 2 parts in an array and adding the static salt in between the two password sections.

We are then hashing the password with sha12 along with the dynamic salt.

My question to you is, is this more secure or just as secure as the 2 methods I’ve linked to? Or am I making it more vulnerable by mixing things up this way?

I also take it storing $password_hash in a cookie along side a username cookie for automatic login is a big no-no? If so, how do websites remember you through cookies in a secure manner?

Answer 1

Assuming that the $dynamic_salt is stored alongside the final $password_hash — since the hash wouldn’t be testable without it — this scheme is quite weak. Using a salt does protect against rainbow tables, but a non-iterated HMAC leaves this scheme weak to brute-force attacks. (The length of the salt does you no good, as it’s a known constant in the hash input. Putting it in the middle of the original password doesn’t really help either.)

Overall, this scheme is far weaker than bcrypt(), as it only (effectively) iterates the hash twice. You’re really no better off than if you simply were storing the password using a simpler scheme such as:

$salt = uniqid();
$password_hash = hash_hmac('sha512', $password, $salt);

But you’re still better off using someone else’s (tried and tested) password encryption routine, rather than cooking your own.

---

With regard to using the password hash in a cookie — this is to be avoided, as it allows an attacker with read-only access to the database (e.g, via a SQL injection attack or a stolen backup) to impersonate any user in your application without knowing or changing their password. It also means that, if a user’s computer has been set to automatically log in, the password hash is stored on it. I’d avoid this.

A better scheme might be to set a randomly generated nonce in a cookie when a user chooses to log in automatically, then store a hash of that nonce in the database. This way, the server can check the correctness of a login key without ever having to “remember” it.