I have a few questions concerning password hashing. I found hash_hmac a pretty good function to hash passwords but a few questions remain.
From another stackoverflow questions someone responded with:
return hash_hmac('sha512', $salt . $user['password'], $this->site_key);
My initial question concerns how hmac uses the key, on wikipedia it seems that the hmac function would prepend the key to every piece of message before hashing it, does the key itself not act as a salt then? Can I then drop the $salt and just use a user specific key instead? hash_hmac('sha512', $user['password'], $this->user_key)
The big question remains the generating of the $salt (or the $user_key from first question). I don't like to store the used salt in the database if I would generate them using rand(). What would then be a good way to generate a user specific salt?
Update
If I would store the salt in the database, is it safe to use:
$user_key = $user['salt'] . $this->site_key;
return hash_hmac('sha512', $user['password'], $user_key);
Use a random per user salt and store it together with the hash in the database. Combine it was a per-site secret that's in your config-file. That way an attacker needs to gain access to both the database and the config-file before he can start to crack passwords.
To hash passwords securely I recommend combining three ingredients:
A good Key-Derivation-Function. It's similar to a plain hash, but it's slow and takes a salt. bcrypt and PBKDF2 are common choices.
A random per user salt. The main purpose of this is that it's different for each user. You store it together with the hash in the database. No problem if the attacker gets it.
A per-site secret. The purpose of this is that getting access to the database is not enough to crack passwords. The attacker needs access to the config file too. And even if he learns the per-site secret the scheme is still as secure as if you had used no secret at all.
Use bcrypt!
The classic text on safely storing passwords:
http://codahale.com/how-to-safely-store-a-password/
Quote from the article:
Salts Will Not Help You
Bonus!
using bcrypt is simpler than finagling your own bs and likely incorrect salting scheme.
DON'T EVER IMPLEMENT YOUR OWN CRYPTOSYSTEM OR SOURCE OF ENTROPY
Related
I understand that bcrypt is more secure than other methods but still puts you the same situation where you need to salt passwords!
If the salt is included in the hash string it's not needed to store it separately in the DB. Everytime I need to create a new hash, meaning a new salt as well, do I have to get all the passwords, extract the salts and check the new one doesn't exist already against my DB passwords?
Wouldn't be easier to store directly the salts separately for easy compare? If yes then I don't get:
the point of storing the salt in plain text
why bcrypt is more secure than manually use sha256 with salted passwords
I'm actually going to disagree with Curtis Mattoon's answer on a couple of things.
When you hash using bcrypt, the salt is stored directly inside the hash, so you don't need to store it separately. I'm not sure what he means by not having to store it at all, because the hash without the salt is completely useless. The salt is needed to verify the password against the hash.
I agree on this point. If you are updating one password, you don't need to update them all. In fact, it would be impossible because you (hopefully) don't know the passwords for any other users.
You don't need to go through pains to get a unique salt. If that were the case, you could use uniqid, but the problem with that is its output is predictable. Predictability is a bad thing in cryptography. Instead, what you want to do is use a pseudo random salt as close to random as possible (i.e. using /dev/random instead of /dev/urandom). If you have a billion users, you may get one or two that have exactly the same salt, but seriously, is this such a big problem? All it does is doubles someone's chance of brute forcing the password for those two particular passwords out of a billion, and I doubt it's even that high of a chance of a collision occurring. Don't strain yourself over this. Make the salts random, not unique. Using things like last login time or IP address is only going to take away from randomness.
As for a comparison between SHA512 and Blowfish, see here SHA512 vs. Blowfish and Bcrypt
This site seems to do a decent job at a brief explanation: http://michaelwright.me/php-password-storage
Quick answer:
1) You don't need to store the salt.
2) You don't need to update all the hashes, if you use a unique salt for each password.
3) I'm no crypto expert, but when you're using a unique salt for each user/password, an attacker would have to use a different set of rainbow tables for EACH user. Using the same salt value across the site means that every user's password would be susceptible to the same hash tables. In the past (for better or worse), I've used a function of the user's last login time and/or last IP as the for their password's salt.
e.g. (pseudocode) $password = hash(hash($_POST['password']) . hash($row['last_login']));
4) I'll defer the "Why is bcrypt better?" question to someone more knowledgeable about such things. This answer may help: How do you use bcrypt for hashing passwords in PHP?
I'm using this code to hash passwords:
hash_hmac('sha512', $password . $salt, $hmac_key);
Is 4096 bits enough for a key?
Thank you!
For password hashing? Sure. Just long enough salt will be enough.
You need to realise, what is the purpose of your using hash here. You're hashing passwords, so that if anyone gets hold of these hashes, they cannot infer original passwords from them. We use salts, so that brute force and rainbow table based attacks are less effective, and we make salts unique for each password, so that two users, using same passwords have different hashes. HMAC does not add anything to security here, except acting as kind of salt.
HMAC is relevant, when you use hashing function as a digital signature of message/file (the way php.net uses it one their downloads page for example). You use HMAC key, so that only people that know this key can verify authenticity of hashed content (as contrasted to php.net downloads, where everyone can check md5 of downloaded file) and to make it more difficult to spoof the message that produces same hash (you need to know the key, to know what hash to target)
For my website's password hashing I wrote the following function:
public function hash($user) {
$user_key = hash_hmac('sha512', $user['id'].$user['email'], $this->site_key);
$password = hash_hmac('sha512', $user['password'], $user_key);
}
I generate user unique keys to use for the final password hashing. Because this key is hashed with sha512 it should give enough security based on what I read on wikipedia:
The cryptographic strength of the HMAC depends upon the cryptographic strength of the underlying hash function, the size of its hash output length in bits and on the size and quality of the cryptographic key.
I have not seen this way if hashing passwords before and was wondering if it is good enough?
Extra: I have not used a salt because I think hmac appends the provided key to the data (like a salt), is this right?
OK, first and foremost. Do not write up your own function to do password hashing. I'm not doubting your skills, but to be safe do not do your own hashing system. And an HMAC your key is OK, but I'd still not use it.
Finally I'd suggest that you do this for your users passwords.
<?PHP
$password=$user['password'];
$username=$user['username'];
$salt='usesomesillystringforsalt';
$hashed_password=crypt($password.$username,'$2a$04$usesomesillstringforsalt$');
?>
This algorithm uses Bcrypt which is based upon Blowfish it is a very robust algorithm and is what Gawker media went to after they were hacked due to the robustness and usefulness for password hashing. crypt PHP Manual
Next up, remember to change the part that says usesomesillystringforsalt to something else. It needs to be 22 digits of base64 salt A-Z,a-z,0-9,/ and "."
Go to that link to find out more about the algorithm itself. I suggest that you just use this implementation as it is much much stronger than the one that you were suggesting.
If you want to go a step forward, I'd suggest that you use a unique salt for every user. If you want to do that, I can write up an example function which will show you how to do that.
As stated, if you have any more questions feel free to ask.
I realize that this topic have been brought up sometimes, but I find myself not entirely sure on the topic just yet.
What I am wondering about how do you salt a hash and work with the salted hash? If the password is encrypted with a random generated salt, how can the we verify it when the user tries to authenticate? Do we need to store the generated hash in our database as well?
Is there any specific way the salt preferably should be generated? Which encryption method is favored to be used? From what I hear sha256 is quite alright.
Would it be an idea to have the hash "re-salted" when the user authenticates? And lastly is it any major security boost to rehash it a bunch of times?
Thank you!
The answer is to not do it yourself. The one-liner that will do everything you need in PHP is to use bcrypt.
Read this, it's easy to understand and explains everything you asked: http://codahale.com/how-to-safely-store-a-password/
bcrypt takes into account the hashing by itself, and can be configured to be as "complex" as necessary to maintain the integrity of your users' passwords in the event of being hacked.
Oh, and we don't "encrypt" passwords, we hash them.
You need to store both the hash and the salt that has been used to calculate the hash.
If you then want to check if an input is equivalent to the original input value, you can re-calculate the hash with the same salt and compare the stored hash with the new calculated one. If they are equal both input values are identical (up to some particular probability).
The choice of hashing algorithm is also important. Because there are fast hashing algorithms and rather slow hashing algorithms. And as you want to make is hard to find a collision (at least in brute-force), use a slower hashing algorithm.
What I am wondering about how do you
salt a hash and work with the salted
hash? If the password is encrypted
with a random generated salt, how can
the we verify it when the user tries
to authenticate? Do we need to store
the generated hash in our database as
well?
Yes. First you generate a salt, then generate a hash from the password plus the salt and save both hash and salt together.
Is there any specific way the salt
preferably should be generated?
I doubt that there's consensus on what's preferable. I use /dev/random. e.g.
$salt = '$2a$12$'
. strtr(substr(base64_encode(shell_exec(
'dd if=/dev/random bs=16 count=1 2>/dev/null'
)), 0, 22), '+', '.')
. '$';
$hash = crypt($input, $salt);
Which encryption method is favored to
be used? From what I hear sha256 is
quite alright.
See Computer Guru's answer, i.e. use bcrypt as in the example above. See the PHP manual page on crypt(). If bcrypt isn't on your system, one way to get it is the Suhosin patch.
Would it be an idea to have the hash
"re-salted" when the user
authenticates?
The salt just makes dictionary attacks slower. If you have a decent random salt to start with I wouldn't think changing it frequently would help. You'd probably be better off investing your effort in making users choose good passwords, changing them often enough and keeping your Blowfish cost parameter at a sensible value.
And lastly is it any major security
boost to rehash it a bunch of times?
That question belongs in the world of cryptographic design. I recommend you leave that to the experts. In other words: forget it—just use best common practices.
What generally you do is something like:
salted = HASH(password . key); // DON'T DO IT LIKE THIS
Where key is "the salt" - the secret key stored in configuration files. So in order to crack the password you would need both the secret key and the DB so it is good to store them
in separate places.
Because the schema I had shown is not strong enough, it is better to use HMAC for this purpose rather then hand written salting. Such an operation is as simple as hash and PHP supports this.
salted = hash_hmac('sha1',password,key); // <-- this is ok
See this: http://php.net/manual/en/function.sha1.php
Three simple rules. Okay, five:
Most important thing, if you want to consider your password storage being safe: allow strong passwords only e.g. at least 8 chars with some different case letters and numbers and even punctuation marks
Allow users to use strong passwords only. Make a routine to check length and character range and refuse weak passwords. Even get yourself John the ripper database and check against it.
Torture users wickedly, beat them up, until they choose good long and random enough passwords. Passwords! Not salt, of which everyone is delighted to talk for hours, but password itself should be random enough!
Salt your passwords and store that salt along with user info. you can use user email and username as a perfect salt, no need to invent something extraordinary random.
Certain algorithm is not that important, you can use MD5 as well. In real world there are very few people who would bother themselves with cracking user database of your famous Fishing And Grocery Fans Society site forums.
So I've been reading a lot about encryption in PHP. So much that I am not sure exactly what's a really good method to securely store login information.
However, the following function is what I came up with:
function loginHash($username, $password){
$salt = str_split($password,(strlen($password)/2)+1);
$hash = hash('whirlpool', $username.$salt[0].'centerSalt'.$salt[1]);
return $hash;
}
Am I doing it the right way? It's used for authenticating a password combined with a username, and the ability to compare the generated hash with the one stored in a database to verify a login.
Encrypting != Hashing. They both are generally accepted to be in the category of Cryptography, but when something can be encrypted, it can be decrypted, which is not the case in Hashing. Hashing is just hashing, and that's it.
The salt is indeed not properly constructed. It should be x-bytes read from /dev/urandom with a fopen() call. For example, 16 bytes of salt is what I personally use. This prevents rainbow table attacks effectively.
To make things more secure, use a secret key, too. For example:
$hashedPassword = hash_hmac('whirlpool',$password.$salt,$key);
The $key is simply random data. You could generate a 64 kB file, for instance, that is called "key.bin" in a hidden folder above the document root and use file_get_contents() before the hash process.
Why to use secret keys? If you store the hashes and salts in a database and the key in the filesystem, then this prevents anyone from cracking your hash if they get their hands on your stored hashes and salts. So, an attacker would need to crack into both the database and the filesystem to crack your hashes, but notice that it's pointless for anyone to crack your hashes anymore if they have already cracked your whole application, which implies that your hashing scheme is good.
My advise is to never, never, never write your own encryption and hash functions. Even experts do it wrong all the time, so dont try it yourself.
Ive heared that phpass (Openwall) is a nice hashing framework, i'd suggest you use that.
They use salts in their hashes and have quite some parameters to tweak the hash.
You're not actually using a salt.
Salt is a randomly generated string that is included in the input for your hash function. As such, it will be different every time.
The idea is that you generate a salt when a user stores a password, and that this salt is included in your data storage. When authenticating, you retrieve the salt and the stored hash, you prefix the given password with the stored salt, and hash the two together. Then compare the result with the stored hash.
I think the above code checks the two boxes.
Avoiding rainbow table attacks (via Salts)
Secure Login
using salt solves two problems:
rainbow tables: rainbow tables are just precalculated hashes, stored with the source value. by comparing the hashes, you get the unhashed value (password). by adding salt you got another layer of complexity - the attacker must know the salt for generating a custom hashing table.
difference of hashed values: without salt, the same 2 passwords generate the same 2 hashes. now it's easy to see if two users use the same password (the weak point here is about the same as with the rainbow tables, but still). that may not amount to much, but is still a point of concern.
additionally, you shouldn't use fast algorithms for password hashing. md5 is fast, sha is fast. the slower, the better.
the matsano chargen blog is a good (and funny) resource for hints and pointers regarding security.