Is this a safe way to store my passwords?

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

I'm trying to increase the level of security with my sites

well, to let you know, no password hashing ussue can increase your site security even a bit.
You have to focus on the other, much more important things such as SQL and file injections, XSS and CSRF vulnerabilities. If you keep your site secure, it will keep your passwords as well safe just as a side effect.

Next thing you have to focus on, is password strength. No hash can secure a a silly password like joe or 123.

As for the hashing itself - you can use whatever you wish, some basic things like using some sane salt like registration time or email and some number of iterations of whatever hashing function is enough. Don't put too much meaning in hashing. it is not the thing that requires SO much attention as inventing some extra-secure original algorithm.

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?

Dunno if you trust me (I bet you won't) but ALL these methods are secure enough and require no impreovement. And affect no security of the site but only passwords themselves in case they are stolen using another vulnerability in your site.

I also take it storing $password_hash in a cookie along side a username cookie for automatic login is a big no-no?

I don't think it's wise thing to reveal a hash itself. But again, it affects no site security but passwords potential vulnerability only. If your hash and password are strong enough, a logic is making me to say that it is safe enough.

Answer 2

This seems like a reasonable salting scheme, although possibly overkill. It probably doesn't need to be 40 characters long - you're just trying to blow up the size of a rainbow table, not make an unguessable nonce - but making it long won't hurt.

As for autologin, you should store (in a cookie) a random token that corresponds to a database entry pointing to the user's account. When the user changes their password, erase all these entries for that user. When generating this token, rand() isn't good enough - you need a secure, unguessable random number. Unfortunately, PHP doesn't really have a built-in facility for secure random numbers - mt_rand() is about as close as it gets, but I personally would directly read random bytes from /dev/urandom on a Linux system and use that to generate my nonce.

Answer 3

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.

Answer 4

Salts can be used,but it has got its own limitations. Another way is using bcrypt.More information can be found at http://www.openwall.com/phpass/

And i think This SO article is more than enough Secure hash and salt for PHP passwords