Secure password hashing and storage in PHP
Everyone knows you should never store passwords as plain text, right?
Recently I’ve come across a lot of bad advice on how to store passwords securely. I thought I’d share a bit of my research into the subject. Like most web developers, I’m not a cryptography expert. However, this should not be the excuse we use when we make a database of thousands of passwords available to hackers. It is quite simple to save passwords in a reasonably secure manner.
Main points: secure password hashing
- Force your users to use secure passwords
- Do not use 2 way encryption, save passwords as hashes
- Salt each password with a unique salt
- Hash the password and salt together multiple times (1000 or more)
- Use an adaptive hashing technique
Cryptographic Hashes
Passwords should never be stored in their original form, instead a cryptographic hash must be stored. A hash function is a function that performs a one way operation on an input producing an output of fixed length called a digest.
A popular hash function is MD5. An example in PHP:
$hash = md5('test'); // 098f6bcd4621d373cade4e832627b4f6
From the hash, the original text cannot be computed, however, knowing the original text you can easily compute the hash. This is the basis of saving passwords securely.
To verify the password, we see if it hashes to the same hash as the one we have stored.
if (md5($password) == $hash) { /* password is valid */ }
Notice how we never store the actual password, only the hash. We also don’t need to be able to decrypt the hash, we only have to verify it given the password supplied by the user.
Note I’m only using MD5 for example, since it is well known. You probably want to use a more secure hash such as SHA256 or Whirlpool as MD5 and SHA1 have a few problems (don’t ask me what they are, I don’t know).
Key Based Encryption
I’ve come across developers advising the use of a key based encryption. However, this is not a secure way of storing passwords. You’re only deferring the task of having to hide the password, to having to hide the secret key.
Another argument is that you need to be able to retrieve the password if the user forgets it. If we backtrack to why we use passwords, we realize that allowing the user to gain access to their account is the concern, not retrieving their password. So instead, send the user a unique key (token) through email or some other authenticated resource, so the user can generate a new password.
Precomputation Attacks - Rainbow Tables and salts
Now, the problem with just hashing a password, is that users normally use very easy to remember passwords, which are thus very easy to guess. Due to this, there are many databases available that map all the possible passwords made up of up of alpha-numeric characters in upper and lower case, as well as a lot of special characters. There are usually in the form of rainbow tables. Most do not have matches for passwords longer then 14 characters however due to the amount of computation required to generate these tables.
The way to beat rainbow tables or any other precomputation attack is to use a salt. A salt is a randomly generated input that you add to the password before hashing. This is done so that the input becomes long enough that generating a table that includes it is computationally infeasible.
So our hash function becomes:
$salt = 'f39ae656bc79a9b2398890bb4';
$hash = md5('test'.$salt); // 1db36e73cf2e68df3640fb1052e801da
Now even if the user supplies a very easy to guess password, such as “love”, it still cannot be looked up in a rainbow table because the table would have to hold the whole input, “lovef39ae656bc79a9b2398890bb4″. No public rainbow tables have that many characters in them.
Use a unique salt for each password
If you use the same salt for each password (a common practice in PHP applications) is a very bad idea. It allows the attacker to crack all your passwords in one go using brute force. Imagine a database with a million passwords. Each guess becomes one million times more likely to match one of those passwords. Using a unique salt for each password prevents this.
Does salt size matter?
Another piece of advice I’ve come across is that the size of the salt does not matter. Using common sense this is not correct. A salt such as “52e801da” will still generate the input “love52e801da” which will be in rainbow tables.
Early Unix user passwords had a vulnerability that was partly due to the size of the salt.
Brute Force Attacks on passwords
Now even though we have mitigated precomputation attacks such as rainbow tables, we still have one issue. We have no way to hide the salt. Since we cannot hide the salt securely, we must assume it is visible. If the salt is visible, the attacker still cannot use a rainbow table, however, they can just guess the password by simply guessing passwords and then hashing them with the visible salt, then comparing the result to the stored hash. This is called a brute force attack.
A brute force attack in it’s simplest form, is to try every combination of passwords in sequence. However, sophisticated forms will use precomputated data such as the word combinations in a dictionary (dictionary attack) combined with statistics to find the password “love” very quickly.
Better Passwords - Key Stretching and Adaptive Hashing
Now the first way to combat this is to force your users to have a password at minimum 6 characters and consist of numbers as well as alphabetic characters in both upper and lower case. This is probably the best thing you could do as you have made the range of possible passwords large enough that a brute force will take a while.
Now you need to slow down the brute force. One way to do this is by using key strengthening. This is the process of hashing multiple times, in order to make the hashing process longer. Hash functions such as MD5, SHA1 are very fast. This is not a good thing for you, since the attacker can do numerous hashes very quickly. However, if you hash 1000 times, then the attacker has to also hash each possible password the same number of times, making their brute force attack 1000 times slower.
Now it is up to you to figure out how many times you want to hash the password. Computational power is increasing every day, so you may also want to increase the number of times you hash the password as time progresses. There are hash functions that take this into account such as MD5 crypt and BCrypt. A lot of why this is needed is explained at this Matasano security article.
PHP implementation of secure password hashing
Now I know this has been a rather long article, so here is what I have come up with that incorporates these methods of mitigating these password cracking techniques.
/**
* Generate cryptographic Hashes for passwords
*
* Features:
* Harderned against precomputation attacks like rainbow tables (using unique salts)
* Harderned against brute force and dictionary attacks (using key stretching and optional secret key)
*
* http://en.wikipedia.org/wiki/Password_cracking
*
* Note: for PHP4 and lower, just remove the "public static" before function declaration
*
* @author gabe@fijiwebdesign.com
* @link http://www.fijiwebdesign.com/
* @version $Id$
*/
class Password_Hash
{
/**
* Generate the Hash
* @return String
* @param $password String
* @param $salt String[optional]
* @param $iterations Int[optional]
* @param $secret String[optional]
*/
public static function generate($password, $salt = null, $iterations = 10000, $hash_function = 'sha1', $secret = '')
{
$salt or $salt = self::generateToken();
$hashes = array();
$hash = $password;
// hash a sequence of hashes, each hash depends on the last one, so any implementation must hash each one individually
$i = $iterations;
while(--$i)
{
$hash = $hash_function($hash.$salt.$secret);
}
return implode(':', array($hash, $iterations, $hash_function, $salt));
}
/**
* Verify a password meets a hash
* @return Bool
* @param $password String
* @param $hash String
* @param $secret String[optional]
*/
public static function verify($password, $hash, $secret = '')
{
list($_hash, $iterations, $hash_function, $salt) = explode(':', $hash);
return ($hash == self::generate($password, $salt, $iterations, $hash_function, $secret));
}
/**
* Generate a random hex based token
* @return String
* @param $length Int[optional]
*/
public static function generateToken($length = 40)
{
$token = array();
for( $i = 0; $i < $length; ++$i )
{
$token[] = dechex( mt_rand(0, 15) );
}
return implode('', $token);
}
}
Example using SHA1 with default of 10000 iterations.
// generating the hash $password = 'test'; $hash = Password_Hash::generate($password); // verifying a password $result = Password_Hash::verify($password, $hash); // dump results var_dump($hash, $result);
Example using whirlpool as the hash function, a 128 length salt as well as a secret.
// define our custom hash function
function whirlpool($str) {
return hash('whirlpool', $str);
}
$password = 'test';
$salt = password_Hash::generateToken(128);
$secret = password_Hash::generateToken(128);
$iterations = 10000;
// generate hash
$hash = Password_Hash::generate($password, $salt, $iterations, 'whirlpool', $secret);
// verify
$result = Password_Hash::verify($password, $hash, $secret);
// dump results
var_dump($result);