Want a useful password cracking solution for your PHP / MySQL application?

Question

After reading the password hashing / salting for a whole day (no lies!), I need to come up with a solution that works, can be used sequentially and it's safe enough for different sites / applications that use a common code base.

So here is the idea of ​​the MySQL user table:

users { id, username, password_hash, password_salt } 

.. and pseudo code:

 $s_algo = 'sha1'; $i_iterations = 1000; $s_password = 'mypw123xyuACE&.!3'; $s_salt = hash($s_algo,uniqid(mt_rand(),true)); $s_result = $s_password; for ($i = 0; $i < $i_iterations; $i++) { $s_result = hash($s_algo,$s_result . $s_salt); } echo 'Password: ' . $s_password . "\n"; echo 'Algorithm: ' . $s_algo . "\n"; echo 'Iterations Completed: ' . $i . "\n"; echo 'Salt : ' . $s_salt . "\n"; echo 'Result: ' . $s_result . "\n"; echo 'Length: (Salt:) ' . strlen($s_salt) . ' (Result:) ' . strlen($s_result) . "\n"; 

The interaction (SQL) between PHP and MySQL is accepted as read, as are the bits of the PHP code that actually verify the given password from the user land against the stored (salted) hash during authentication. This is not rocket science. This is in terms of what all of this has already been done, but with a non-deleted hash password store.

From my reading, I suspect there could be endless debate about what really should be $ s_algo (normally, maybe NOT md5), as well as $ i_iterations. Therefore, let's just consider that they are variables in this problematic scenario, which may vary depending on the specific context, that is, storage restrictions, server loading problems, etc.

In general, does this methodology for creating passwords written for each user in PHP sound like that? Is a for loop needed at all? Is the salt creation source code ok? Is the excess of excess salt, taking into account storage (equal to the final hash length). Please people, select the holes (but not too many!) ..

Other thoughts:
- How about hash_hmac () is a critical improvement over several hash () iterations?
- PBKDF2?

Answer 1

Sorry, I would comment on the post, but have not yet received enough reputation.

I would use SHA256 for my hash algorithm and continue to iterate around 25. More than that, and this is really redundant. I use a very similar framework solution that I applied to half a dozen sites. I chose to create a too complex random symbol generator, but I used it in many other places, including those with financial data symbols.

Other editing: use a random character generator, for example, for salt:

 function randomChar($length) { $characters = array("A", "B", "C", "D", "E", "F", "G", "H", "J", "K", "M", "N", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z", "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "~", "!", "@", "#", "%", "^", "&", "(", ")", ":", "{", "[", "]", "}", "|", "<", ">", ".", ",", "/", "?", "_", "+", "-", "="); $charactersNumber = count($characters); $charactersNumber--; $randomLength = 0; while ($randomLength < $length) { $currentCharacter = $characters[rand(0,$charactersNumber)]; if ($currentCharacter == $previousCharacter) { $currentCharacter = $characters[rand(0,$charactersNumber)]; } $random .= $currentCharacter; $previousCharacter = $currentCharacter; $randomLength++; } return $random; } 

The answer to the iteration question: If x = hash (password + salt), then x = hash (x + salt)

and 1 estimate x takes 10 ms, then 2 takes 20 and so on. So ... 25 ratings = 250 ms and 1000 = 10 000 ms.

Until it takes 10 ms for each of them, even .5 ms for more than 1000 is still half a second.

If you only accepted alphanumeric passwords and the password was 8 characters long, each iteration would add 62 ^ 8 (if they had not found the password) more hashes because they had to do another, for each combination they tried.

Answer 2

Yesterday I read an article in response to one of my security questions here: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to -know-about-s.html

It specifically states that the faster encryption is the worst, the more it and MD5 and SHA1 are among the worst. Despite the fact that they are located in microseconds from each other, this leads to very long times of creating a rainbow table.

I read the following in php manuals: http://www.php.net/manual/en/function.hash.php#89574 , where the guy checked the test of each ego and came up with the speed of each of them. And based on my testimony, and that I use RipeMD with a 50-character salt. What you asked: The fact is that you generate a random salt and then save it in a database that seems unnecessarily redundant. I personally would prefer to have one salt hidden in my php code, rather than many unique salts embedded in the database. Plus, why do you hash the salt?