Pretty much what I said in the article: try to use scrypt if you can, if you can’t, then follow the Matsano recommendations, in the order stated:
N=2^14, r=8, p=1
- PBKDF2 with SHA256:
We used #3 in Discourse with 64,000 iterations… the tricky part is you need to increase iterations as time goes on and hardware gets more capable, but that invalidates previous password hashes, too, so you need to version them somehow.
Old versions of software have comically bad hashes. Look at NTLM versus MD5, it’s nearly twice as fast to beat. And those old software user databases are sitting out there, forever, waiting for someone to find the hashes…
Well, some ideas are simply (and sadly) ahead of their time and fail.
Wow this is so hardcore!
To use Blum’s method you must memorize two things: a random mapping of letters to digits, and a random permutation of the digits 0 through 9. The random map and the random permutation are your personal keys so you must keep them secret. They must be truly random — any pattern that makes them easier to memorize may make your system easier to break — and that’s why this up-front memorization is hard. But it only has to be done once.
It’s fair to note that Scrypt is pretty new, having been invented in 2009, but it was a reaction to very fast custom hardware that is now … almost everywhere.
Any of the 3 I listed at the top of this post (and Matsano recommended) would work fine. The numbers in the GRC checker are for really simple worst case scenario stuff like MD5. You can multiply those by… a lot. I mean compare these numbers from actual GPU crack tries … note that these are in millions of attempts per second!
- MD5: 11,616
- SHA1: 3,703 (3.1 × slower)
- SHA256: 1,526 (7.6 × slower)
- SHA512: 568 (20 × slower)
- Bcrypt: 6916 (1.6 × slower)
- Scrypt: 21 (553 × slower)
Be careful because this also depends on the # of iterations chosen, though! That’s why they recommend a large number of iterations because that’s also a divisor here, you are not calculating this hash once, but (n) times.
You have to plan for worst case, because you have no idea what hashes are being used behind the scenes, and how old the software is.
I do think it’s a good idea for users to know that really and truly they need to be picking passwords of at least 12 chars in length if they don’t want their stuff trivially compromised when the user database leaks – particularly since users re-use passwords all the time! So all it takes is one leak with a 9 or 10 char password and that email/password combo is now burned on every service. Triply so if like most users they only used uppercase/lowercase or lowercase/number!
That’s why Discourse is open source… anyway, this is about reasonable defense, and I no longer believe that an 8 character password is remotely a reasonable defense even for an average user. With the hardware that’s out there, 8 character password hashes, even using the full complement of ASCII available, are a joke to crack. Trivial.
I am a big, big fan of using the domain name as part of your personal “formula” for the password you use (like a kind of salt, basically). It makes a lot of sense and I recommend it.
All fine, but make sure that simple password is at least 12 characters. And has uppercase, lowercase, and numbers.