On Tue, Dec 04, 2007 at 09:36:21AM +0100, Sebastiaan van Erk wrote: > John Krasnay wrote: > >I see from your later posts that your requirements are not that strict, > >but if anyone else on the list needs to do password hashing, here's one > >of the best articles I've seen on it: > > > >http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ > > > >jk > > This article is a total rant with lots of stupid inaccurate information.
I disagree. The author's tone is a little condescending, but IMHO his advice is bang on. > For example: > > 1. take a “dictionary” —- say, of all combinations of > alphanumerics less than 15 characters > 2. 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. > Again you've got more to worry about when you lose your SQL database. > It's all about risk management. You can change your password hashing > from salt + MD5 to a high grade industrial strength solution. But it's > wasted effort: because MD5 + a long salt is not even close to the > weakest link in your system, and your total security is only as good as > your weakest link. 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. 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. > And with passwords, the weakest link is always the > user; you'll have 1/2 of your password database cracked anyway by a > simple dictionary attack if you lose the database. The whole point of using random salts + slow hashing is to make even simple passwords hard to crack when your DB is stolen. > 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). jk --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
