Comments on: How to store passwords safely with PHP and MySQL

By: ElbertF

ElbertF — Mon, 01 Mar 2010 06:19:51 +0000

Fixed it, thanks.

By: garyamort

garyamort — Fri, 19 Feb 2010 02:11:44 +0000

The above is good for a general rule of thumb, however one must always be ready to be flexible when needed.

For one thing, not all websites are a vacumn, thus whatever mechanism you may include the OPTION of validating at least initially to a different format. For example, many systems do store MD5 passwords, and it is a simple matter to export them when migrating. So for a special use case[migration of users], you would want to allow the user to sign in using their old password, and then immediately rehash and save it.

Additionally, you may be working on a web service for other users, in which case there should be an option to export data in a manner which allows people to use that data on their own server. Locking people into your system is rude and obnoxious, there should always be a migration option.

Lastly, there are indeed times when you will need to allow a site owner to log on as someone else. Customer service is key. In those cases, explaining how much more secure the password system is is useless, you must give them a way to log on. Either store the password in some manner that they can look it up, or provide functionality to allow an admin to “impersonate” a user.

By: Name

Name — Thu, 18 Feb 2010 09:05:23 +0000

<———- CORRECTION TO THE ABOVE ————->
I had a typo in there . . .

Doesn't work as written. Need to concatenate the user's input password with the salt again after getting it from the login form . . .

… . $r = mysql_fetch_assoc(mysql_query($sql));

// The first 64 characters of the hash is the salt
$salt = substr($r['hash'], 0, 64);

$hash = $salt . $password; <—————— (TYPO FIXED) INSERT THIS LINE HERE (IN 2ND CODE SECTION)

// Hash the password as we did before
for ( $i = 0; $i < 100000; $i ++ )
{
$hash = hash('sha256', $hash);
} … . // ETCETERA

By: Name

Name — Thu, 18 Feb 2010 09:02:49 +0000

Doesn't work as written. Need to concatenate the user's input password with the salt again after getting it from the login form . . .

… . $r = mysql_fetch_assoc(mysql_query($sql));

// The first 64 characters of the hash is the salt
$salt = substr($r['hash'], 0, 64);

$hash = $hash . $password; <—————— INSERT THIS LINE HERE (IN 2ND CODE SECTION)

// Hash the password as we did before
for ( $i = 0; $i < 100000; $i ++ )
{
$hash = hash('sha256', $hash);
} … . // ETCETERA

By: ElbertF

ElbertF — Tue, 16 Feb 2010 01:28:16 +0000

Because a potential hacker would be able to brute-force the password on another machine without using sleep(). You need the algorithm to be slow.

By: PA

PA — Mon, 15 Feb 2010 17:16:52 +0000

Why not use the sleep() function instead of hashing multiple times ?

Then :
- you wouldn't increase the chance of collisions
- you wouldn't increase the server load

By: ElbertF

ElbertF — Fri, 12 Feb 2010 01:41:12 +0000

Yes that's true. If you're simply after the admin password and know the full hash and algorithm the random salt won't make a difference. The only thing that can help you is a strong password (you could store the hash on a different server).

Hashing multiple times may increase the chance of collisions slightly but I don't think it matters to much in this case. You'd still have to perform the hash a 100,000 times which slows brute forcing down significantly. If computers get faster you can just hash all the passwords some more.

By: Tijn

Tijn — Thu, 11 Feb 2010 18:33:02 +0000

I don't fully understand what the random salt is for. A single site-wide salt is bad because “someone with access to your code can find the salt”, but I don't see how prefixing the hashed string with a random salt makes any difference.

If I have access to the database, I could just look at the first 64 characters and create a new rainbow table. The only real difference is that it will take more time to “decode” the password of ALL users, but when you're looking at a single password, this method doesn't seem more secure.

Also, I'm not a security expert , but is it really better to hash something multiple times?

By: Tim Cinel

Tim Cinel — Mon, 01 Feb 2010 02:21:17 +0000

That's a big salt. I was thinking it would be better to have a secret component in the salt but upon further thought it wouldn't help.
Thanks for the article ^^ Death to plaintext password storage!

By: ElbertF

ElbertF — Mon, 01 Feb 2010 01:37:46 +0000

Thanks Ramon! Actually it's the opposite, strtolower() makes sure the login to is case insensitive (in the SQL query case doesn't matter).

By: Ramon Fincken

Ramon Fincken — Sun, 31 Jan 2010 15:14:49 +0000

I like your article !

However you presume usernames are fixed and TheName is another user as thename > strtolower($username)