Likely the most painful password hashing discussion you'll ever read

Nobody has explained this better than Coda Hale:

http://codahale.com/how-to-safely-store-a-password/

(in place of "bcrypt", you can substitute "PBKDF2" [weaker] or "scrypt" [stronger], but all those options are just fine).

The problem with md5 and sha and such is that they are fast. bcrypt is useful because it takes a fixed amount of complexity which can be specified by the programmer (and later increased). It also uses salts to thwart rainbow tables. The complexity bit is important, though, because as computers get better, you can make it harder to reverse your passwords.

Also, the biggest reason any of this is a problem is because password reuse is rampant. You are being entrusted with the password to your user's life - their email, their bank account, their facebook account... treat it with respect.

Is there any reason most programmers should know any of this ?

The code should look more like this(and should use a standard library):

import Password_protector

P = Password_protector(date_of_first_use) #library upgrades algorithms every once in a while, only a single algorithm available per date. If there's a need for automatically upgraded hashing library should handle covertly.

protected_password = P.protect_password(password)

if P.compare_password(password, protected_password) == True ...

Or something similar. That at least should cover the basics - safely.

The reason why MD5, 3DES, and similar algorithms aren't really recommended in 2014 is that they're very fast/efficient on modern hardware. This is due to utilising GPU cores to do the hashing (which wasn't done back when MD5 was popular). This means the "time to crack" is low.

Here is benchmarks of different hashing algorithms (faster is WORSE): http://thepasswordproject.com/oclhashcat_benchmarking

But the really nice part about things like BCrypt and PBKDF2(Rfc2898) is that they accept "rounds." Which is number of repeated iterations over the password+salt. So every year you can respond to faster hardware by adding more rounds (e.g. 2014, have 10K rounds, in 2020 have 15K rounds, etc). If MD5 had supported rounds, it might still be safe to use today with enough iterations.

Even things like BCrypt and PBKDF2 will eventually fall by the wayside (MD5 used to be a more secure alternative to the much faster DES algorithm). But at least rounds (additional iterations to respond to changes in hardware) will keep them relevant for longer.

You use a salt to mitigate this but even if you use a salt, it _has_ to be stored somewhere. Once an attacker has it, they'll be able to create rainbow tables with this in mind.

You then move to using a different salt for every password so any rainbow table only works for one result but if you use a fast hashing algorithm, attackers will still be-able generate rainbow tables based on those salts.

So you pick a slower hashing method but in the future, as computer hardware advances, you'll be in the same situation where it's trivial to brute force some rainbow tables.

So you need to keep on top of it and keep updating the stored hashes with something that is non-trivial to brute force, in PHP this gives you these functions: http://php.net/manual/en/ref.password.php.

In reality though, in the event of a breach, all you're doing is buying time for your users to change their passwords before the relevant rainbow tables are generated, so the next important step is to let your users know their hashed passwords were leaked, you followed best practices, but they should update the passwords wherever they used it.

A SQL injection vulnerability lets you get the MD5 hashed passwords out of a database. As most people don't use 17 character passwords, you can check the MD5 hashes against a rainbow table (you can even do it online) and probably find a privileged user account pretty quick.

I actually broke into a legacy system my predecessor programmed in this manner when I couldn't find documented admin credentials.

MD5 is fast - and while computational speed is normally your friend, with cryptography it's your worst enemy. Simply put, the faster the cipher, the more break in attempts a cracker can have per second.

This is why password strengths are often represented in duration (ie how many years would it take to crack). Though those figures are hugely estimated - to the point of being practically worthless.

KDFs are meant to require a great deal more computation (e.g. an example of PBKDF2 might iterate HMAC-SHA256 8,000 times).

If your 17 characters are 3 lowercase non-archaic English words, maybe with two digits at the end, then a codebook for them already exists in MD5.

In practice, we don't know how crypto analisys will evolve, and non-broken algorithms are free for use, and just as easy as MD5. So, why do you insist on using a broken one?

- Bad advice is posted everywhere.

- Good advice is disregarded because nobody reads the preceding posts in the discussion.

The question was "I want to store password[s] in encrypted form." The answer should have been immediately -- "you don't encrypt passwords, you hash passwords using a well known, established, and tested cryptographic hashing algorithm + a salt, damnit!"

Then I noticed "PHP" and then I was enlightened.

Do you have any specific examples of bad security advice in the documentation? I can try to raise hell with the doc maintainers and maybe even suggest an amendment.