John Krasnay wrote:
For example:1. take a “dictionary” —- say, of all combinations of alphanumerics less than 15 characters2. hash all of them 3. burn the results onto a DVD.The keyspace is size is 62^15-1 = 768909704948766668552634367. That means if you can save a hash in 1 byte you still need about 143220593211942663 DVD's.Yeah, but that really doesn't really take away from his argument.
I think it does. Makes me wonder if he knows what he's talking about for one. He suggests you do something which is impossible, and with a condescending tone at that.
First, no one in this thread has even mentioned salts, yet a password hashing scheme without them would be completely inadequate. Further, the author correctly points out that a randomly-generated salt, stored with the password hash, is far more secure than a "secret" constant salt.
I certainly mentioned salts. :-) And a "secret salt" is not a salt, a salt by definition has to be random.
Second, the "high grade industrial strength solution" the author suggests is salt+BCrypt instead of salt+MD5. Sure, it's a little more effort to download jBCrypt (http://www.mindrot.org/projects/jBCrypt/) than to use MD5, but not that much. The whole point of using random salts + slow hashing is to make even simple passwords hard to crack when your DB is stolen.
I certainly don't disagree with you (or the author) that using BCrypt is better that MD5. But it won't protect your weak passwords. Sure, it'll take a little more effort; but the protection will not be enough. I've seen dictionary attacks on actual password databases with a relatively small dictionary succeed on > 50% of the passwords. With botnets or other distribution methods, testing an entire dictionary (plus simple variations) will always be feasible.
And the users will blame YOU for losing it, so don't.Hey, there's some good security advice. Don't worry about your password hashing scheme, just don't let anyone steal your database. Ask the guys at Reddit how that worked out (http://blog.moertel.com/articles/2006/12/15/never-store-passwords-in-a-database).
I'm not saying NOT to use a password hashing scheme. But I think in the reddit case blaming it on the absence of password hashing is just finding a scapegoat; they had some MUCH MORE SERIOUS security failures when they let their database get stolen. Security failures you are NOT going to fix by introducing password hashing.
For example, some elementary questions:1) what was their security policy that allowed somebody who is unauthorized to access the backup database? 2) if the backup contained confidential information, why was it not encrypted?
My original point was that MD5 hash plus salt is adequate in most use cases; and I still stand by that. If you're developing a high profile site, then I STRONGLY suggest you hire a security expert to audit your entire site: security policy, operating procedures, and systems.
Regards, Sebastiaan
smime.p7s
Description: S/MIME Cryptographic Signature
