[cperciva]

Remember, security against cracking is a combination of password strength and key derivation function strength. Nothing will save you if your password is "password". Not much will save you if your password is hashed with MD5.

But scrypt can be over 100,000,000 time stronger than MD5 -- so if you're using scrypt you can afford to use a password which is 100,000,000 times weaker. "jdtwbv" hashed using scrypt is stronger than "H.*W8Jz&r3" hashed using MD5.

[raverbashing]

""jdtwbv" hashed using scrypt is stronger than "H.*W8Jz&r3" hashed using MD5"

Is it? I'm not sure.

for the first one you're using lowercase letters (and digits, I'm giving you that 'free')

For the first one we have 36^6 For the second one (all printables) 100^9

Relation between them: ~ 459,393,658. If you're saying scrypt is 100M times better, in this case the second one is safer

And the relation is important but less as computers get faster. Option B may take 1Mi times as long as Option A but if Option A takes 1 microsecond, there goes your Option B as well

[cperciva]

If you're saying scrypt is 100M times better

Oops, you're right, I got the math wrong when I looked at the table in my paper. I should have said that scrypt can be over 100,000,000,000 times stronger. ;-)

[danielweber]

People have built huge rainbow tables of MD5 hashes.

I don't really keep up with that game (like WoW, it seems like a fun game, but only if you are willing to put in a lot of your time), but I think the current limit is somewhere around 8 or 9 characters if you are pulling from all printables, meaning that "H.*W8Jz&r3" with MD5 is probably not breakable right now.

Take off two characters, or wait 3 years, and it probably will be.

[consultant23522]

My understanding, and I'm sure that someone else will correct me, is that with MD5 rainbow tables it's not so much that someone will get your password as they will get something that hashes to the same value. More than likely this will be your password, but sometimes not. The point is that it doesn't matter if your password is 25 characters long.. if there's a 5 character password that hashes to the same value they could log in with it.

[danielweber]

While it's possible to make MD5 collisions, finding something that hashes to the same thing as a hash of my short password is essentially impossible.

In fact, collisions on short passwords are harder than collisions on long passwords. The space of all MD5 outputs is way bigger than the space of 12-character passwords.

[dspillett]

> "jdtwbv" hashed using scrypt is stronger than "H.W8Jz&r3" hashed using MD5*

But "password" is still grossly insecure in either case, it'll still be the first thing that someone performing a dictionary attack will try. Never tell people how good your key derivation function is, lest they misunderstand and think it means they don't have to chose a non-obvious password/passphrase.

[dublinclontarf]

Just use bcrypt :-p

[tsahyt]

bcrypt is not bad and you're definitely better off with that than with MD5, but scrypt performs better for these sort of things. There was an article on HN a week or so ago about this.

[Xylakant]

One of the problems of scrypt is a lack of language bindings. There's no officially blessed language binding for PHP, there's a ruby gem that only works on MRI but doesn't support jruby. Bcrypt on the other hand is widely supported, simple and easy to use implementations exist for devise and activerecord for example. I'd pick the slightly worse but widely supported algorithm and rather tune the work factor than being stuck with an extension that might or might not be supported depending on the authors availability of time and resources.

This all can change, but that's the current state of things. Sorry scrypt.

[Freaky]

> there's a ruby gem that only works on MRI but doesn't support jruby

Works as well as any other MRI extension, which is to say pretty well:

    jruby-1.7.4 :001 > require 'scrypt'  
     => true   
    jruby-1.7.4 :002 > SCrypt::Password.create("bla")  
     => "400$8$2d$096ac4e8a120a4f9$d1e13bbfa387196d68f116d76ae23d0d3ffa39c891192a56832db0a1d8f6a8ec"

Yay for ffi.

[Xylakant]

Well, C-Extension support in jruby is wonky at best. It works for some and doesn't for others and is sometimes scheduled to be removed. Granted, this one works, I stand corrected. There's a full java implementation for scrypt as well. However, my point still stands: There's no integration in devise, none in rails. No PHP implementation.

It's all fairly easy to change, but nobody has done so :)

[Freaky]

Devise: https://github.com/capita/devise-scrypt PHP: http://pecl.php.net/package/scrypt

So not quite "none", though granted being some random third party addon might as well be for many people (and possibly a good attitude to take for something security-critical).

[rypskar]

I think that since bcrypt is more available I will continue recommending it, and using anything else should be based on a risk assessment. I do not think peoples that don’t do risk assessment on storing password will care enough to spend time on something that is not easy to set up when it “only” affect security

[hackerboos]

http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html

[tptacek]

That article was simply wrong. The chart at the top of it was added after it was pointed out that PBKDF2 is worse than bcrypt as a password hash, and the chart refutes the article.

[est]

Great article. Old discussion here

https://news.ycombinator.com/item?id=3724560