Password encryption

[nameless1]

Hy 2 all,I have some questions about password security that I haven't been able to find an answer yet. Hopefully you guys know.Here it goes:1. Is it better to hash(sha2) the password and then salt it or salt it and than hash it ?2. I'm guessing that using a random salt is better than the same salt used for every password.3. How can you generate a different random salt for each password ? I mean how will the login page know which random salt to mix with the hashed user inserted password and then to compare it with the password stored in the db. (an example would be great(for both: generating and authentication)4. I saw some codes in which the salt and/or hash and/or password was split into two (ex: hash.salt1a.password.salt1b or password1a.salt.password1b or salt.hash1a.password.hash1b etc.) Is this a good idea ? Is it really more secure ? If so which would be more secure (splitting the password, the hash or the salt) ?5. Is double hashing (ex: (sha1(md5($password))) any good ?6. I've been reading something about password salt and pepper ?? What exactly is pepper ? Is it some sort of second salt ?If somebody could enlighten me about these questions, that would be great.Thanks in advance!

[Err]

I should note right now, there is no consensus on any number of methods used. But generally, for practical purposes, using sha1() and a randomly generated salt or two ensures good security. Obviously it's not the best method you can do, but I find it that doing that suites MY needs and level of protection just fine.I can help you with #3 at least. An example:

  $salt = uniqid();  $pass = sha1($pass.$salt);

Then save $salt in the database so you can reference it again later.

Edited April 30, 2012 by Err

[nameless1]

Thanks a lot! But wouldn't it be more secure if I stored the $salt in include.php or some other file rather than in the database ? If an attacker gets all the info from the database, then he also has every unique salt.On the other hand how will the login script know which salt to get from the list, if they're all in a single file. Any ideas ?

[Err]

If the database is compromised, then they probably already have access to sensitive information they were trying to access. Same thing with the web server, if someone gets access they can get to your include file.If you want to save salts in a include file you can use arrays.

[birbal]

1. Is it better to hash(sha2) the password and then salt it or salt it and than hash it ?

you should have salt it first

2. I'm guessing that using a random salt is better than the same salt used for every password.3. How can you generate a different random salt for each password ? I mean how will the login page know which random salt to mix with the hashed user inserted password and then to compare it with the password stored in the db. (an example would be great(for both: generating and authentication)

you can use user credential to salt it which is basicaly quite random. eg you can use timestamp of user registration which will never be same for two user. or any other credentials. you can mix up more than one user crdential eg mixed with emailid nick timestamp.

4. I saw some codes in which the salt and/or hash and/or password was split into two (ex: hash.salt1a.password.salt1b or password1a.salt.password1b or salt.hash1a.password.hash1b etc.) Is this a good idea ? Is it really more secure ? If so which would be more secure (splitting the password, the hash or the salt) ?

it will be a good one. you can split the strings and juggle it around to construct completely different string.

5. Is double hashing (ex: (sha1(md5($password))) any good ?

it will make it more harder to decrypt. You can use mixed up different hash function to make it more complex so thus it will be hard for attacker to decrypt using rainbow tables for particular hash.also use a server specific salt which is hardcoded. storing salt in database is not a good idea. a successfull sql injection could loosen the effeicency of salt Edited April 30, 2012 by birbal

[nameless1]

Thanks guys for the HELPFUL info!

[boen_robot]

I'm surprised no one tried to explain the purpose of a salt, as the answers to most questions can be inferred from that.First, the purpose of hashing a password helps IF an attacker somehow gets access to your database - if they do that, they'll see the hash, rather than the original password. But what if two or more of your users use the same password (like "123456" for example... that's one very popular password)? The attacker won't know the original password at first, but he'll see all users that have this one password. Cracking that one password will unlock not just the one user, but all users that have this password.That's where a salt comes in... The goal is to make hashes for the same password different. That way, an attacker wouldn't know if two users share the same password. Cracking one hash will only make the attacker gain access to that one user, not everyone who shares that password. But how to do that? If you combine a randomly generated string with a password, you ensure the resulting hash will be different. The randomly generated string is refereed to as "salt". The only way an attacker could know two users share the same password is if both the hash and the salt are the same, but since the salt is randomly generated, the chances of that are very slim.In order to be able to reproduce the hash, you need to store the salt along with the hash. That way, when users authenticate, you'll add the previously generated salt, and see if the hash is the same as the hash in the database.So with that in mind (speaking of which, I'm sorry for the headache you're about to have)...

1. Is it better to hash(sha2) the password and then salt it or salt it and than hash it ?

The two things are done together. You combine the salt with the password, and hash the resulting string.

2. I'm guessing that using a random salt is better than the same salt used for every password.

Yes, because if you were to add the same salt string, you'll defeat the purpose of a salt - If two users use the same password, combining them with the same salt string would produce the same hash.

3. How can you generate a different random salt for each password ? I mean how will the login page know which random salt to mix with the hashed user inserted password and then to compare it with the password stored in the db. (an example would be great(for both: generating and authentication)

You can generate a salt in various ways, one of which is to get a hash of the current time, which you can know is different for every user (especially if you use microtime()). But there is no way to generate the same salt twice, which is exactly why you also need to store the salt in the database too.

4. I saw some codes in which the salt and/or hash and/or password was split into two (ex: hash.salt1a.password.salt1b or password1a.salt.password1b or salt.hash1a.password.hash1b etc.) Is this a good idea ? Is it really more secure ? If so which would be more secure (splitting the password, the hash or the salt) ?

Yes, but not by much. The only way for an attacker to know two users share the same password is if all password pieces and salts match, but since all salts are randomly generated, the chances of all of them matching are even more slim than just one matching.But the difference in security here is like saying you're 99.99999% percent secured as opposed to 99.9999%.

5. Is double hashing (ex: (sha1(md5($password))) any good ?

Similarly to the above, yes, but it's not significantly better. The outer hashes can be easily brute forced (since the number of possibilities is limited), and only the inner most one makes the difference. In fact, if your inner most one is md5, that's actually worse, because MD5 can nowadays very easily be decrypted (maybe not to the original password, but certainly to a string that would generate the same hash).Alternatively, if an attacker knows how you do the hashing, they may treat the whole sequence of hash functions as one giant hash function, so in the end, it will take them pretty much about the same time to crack a password (except that they'll need a few more milliseconds for each attempt).

6. I've been reading something about password salt and pepper ?? What exactly is pepper ? Is it some sort of second salt ?

Where have you read that? From the very limited Google Search I've done, it seems the goal is basically the same as the goal behind splitting the salt (decrease the chances of the salt and hash being repeated), only instead of splitting the salt, the idea is to randomly choose a number/string that corresponds to a method by which to combine the password and salt. That way, for an attacker to know a password is shared between users, the hash, the salt and the "pepper" must all match, and to find out the original password, the attacker must implement all "pepper" methods, and switch them accordingly for each user.Similarly to splitting the salt, this does not improve security significantly, but unlike double hashing, it can't make security worse. Between splitting the salt and using a pepper, I think I'd go for a pepper, but that's mostly a matter of preference. From an attacker's point of view, both are equally hard to crack - in either case, to know the password is the same, all components would need to match, and to do cracking, you need to know how the salt(s) and hash(es) are combined, which can be a single method (without a pepper) or multiple methods (with a pepper), but if an attacker could find out one method, he'd probably find out all pepper methods too.

[justsomeguy]

I'll add that it's better to use a more computationally-expensive hash function, like SHA-256 or SHA-512. For extra special bonus points, put the code that combines the salt and pasword into a hash in a loop so that it runs the hash 10 or 20 times. The point is to make it take longer to compute the hash. If you only use sha1 once, assuming someone knows your salting algorithm, then maybe they can run 1 million computations every second to try different passwords and see if they match. If your salting algorithm involves looping 20 times and running SHA-512 each time then maybe they can only try 100 every second or something. So the point is to make attacks like that take longer.

[Don E]

JSG and/or Boen,Can either of you or both provide an actual working example of the above procedures/methods? Meaning, from the the time the user chooses a username/password and submits to be inserted into a database; the procedures between those two points in the methods described above. I would greatly appreciate it.Thank you!

[boen_robot]

Upon registration:

<?php//Validate input here, and assign $username and $password with the valid values$salt = substr(sha1(microtime()), mt_rand(0, 17), 22);$passwordHash = crypt($password, '$2a$31$' . $salt);//Assuming we're already connected with MySQLi and have the connection in $mysqliif (!$mysqli->query(    "INSERT INTO `users` (`username`, `password`, `salt`) VALUES ('" .    $mysqli->real_escape_string($username) . "', '" .    $mysqli->real_escape_string($passwordHash) . "', '" .    $mysqli->real_escape_string($salt) . "')")) {    //Error upon adding the user... perhaps some uniqueness criteria wasn't met.}//Done!

Upon login:

<?php//Validate input here, and assign $username and $password with the valid values//Assuming we're already connected with MySQLi and have the connection in $mysqli$result = $mysqli->query("SELECT `password`, `salt` FROM `users` WHERE `username` = '" . $mysqli->real_escape_string($username) . "'")->fetch_assoc();if (!is_array($result) || $result['password'] !== crypt($password, '$2a$31$' . $result['salt'])) {    //Wrong username or password}//OK

About the part '$2a$31$' - That selects the "blowfish" algorithm with maximum computational complexity - i.e. it takes most time to make an attempt. See crypt()'s manual page for details.And about the line

$salt = substr(sha1(microtime()), mt_rand(0, 17), 22);

Blowfish accepts a 22 character long salt that can contain decimal numbers, latin letters, "." or "/". I chose to limit the salt to simply being a hex number - i.e. every character is a decimal number or a letter between A and F. To make it 22 characters long, I get a 40 character sha1() hash of the current microtime, and get a 22 character portion of it. The portion starts at a random place between the first and 18th character (character counting starts at 0), thus ensuring that the resulting salt is exactly 22 characters, and not less.As said before, there are other ways to get a salt. I used this one because it's simple, while still being secure enough.Note also that the "pepper" (as in "the combining of the password and salt") here is left up to PHP, or to be more precise - to blowfish itself.

[Don E]

boen, Did you add this for added security?

'$2a$31$'

Edit: Explained above.

Edited April 30, 2012 by Don E

[Don E]

Nm. Got it.

Edited April 30, 2012 by Don E

[justsomeguy]

Your if statement is the same as something like this: if ($var == $var) You're comparing the exact same things to each other. The point is to store the hashed password in the database and then when they log in you take the password they entered, get their salt from the database, build the hash the same way you did before, and compare that hash with the one saved in the database.

[Ingolme]

Is it safer to generate the salt with known information rather than having to store the salt in another database field?For example, using several user attributes that never change, such as a hash of the user ID, registration date and the password itself.

[justsomeguy]

I don't really think it's any safer, assuming your hashing/salting algorithm is suitably complex (e.g., something other than hash($pw . $salt)). If they have your database and your hashing algorithm then they also have the salt, regardless of whether you store it in the database or get it from other fields. Basically, you need to design for the worst possible case, which is when an attacker has your complete database and all of your code. If they have that then they can figure out what the salt is, so it doesn't really matter if you just store it in the database.

[nameless1]

Thanks for the info guys :DI've been searching and reading for the last 2 days about PHP password Cryptographic hashing.The most common and secure functions I came across were sha256/512 , bcrypt , HMAC , PBKDF2(Password-Based Key Derivation Function) and PHPass.From what I've been reading speed is an enemy (http://codahale.com/how-to-safely-store-a-password/)So I've been looking for the "slowest" secure hashing algorithm which I found is bcrypt and PHPass (http://www.openwall.com/phpass/).Now I can't make up my mind which one to use. :confused:What do you guys think? Which one should I go with and why?Just to make sure:1. bcrypt = crypt_blowfish right ?2. bcrypt and PHPass are both hash + salt functions ? I mean I don't have to add salt, they already have the salt function built-in.Thanks in advance!

[justsomeguy]

PHPass will use bcrypt first if the system supports it. You don't need to supply a salt for PHPass, it stores the salt with the hash.

[boen_robot]

Just to make sure:1. bcrypt = crypt_blowfish right ?2. bcrypt and PHPass are both hash + salt functions ? I mean I don't have to add salt, they already have the salt function built-in. Thanks in advance!

1. Since PHP 5.3, yes. PHP includes it's own implementation (PHPass) which it uses if the OS doesn't have native support. So it's not a question on whether you should use PHPass or bcrypt or PHP's built in crypt() function - they are all the same thing.2. You need to generate a salt and supply it in the second argument of the crypt function (per the above example), and doing so leaves blowfish to decide how it will combine the salt with the data...

You don't need to supply a salt for PHPass, it stores the salt with the hash.

...unless maybe I'm missing something... like, WTF?