> - With a computer of 8,000 NOK (~ 1400 USD), you can do a few hundred million attempts per second.
Are you kidding me? LinkedIn stored their passwords using (salted) SHA1 using no iterations? Jesus.
Are you kidding me? LinkedIn stored their passwords using (salted) SHA1 using no iterations? Jesus.
http://www.tarsnap.com/scrypt.html
It requires a lot more memory to brute-force it, thereby defeating any speed gains from parallelism.
"use bcrypt" has become an HN meme, with all the bad implications of it
As if scrypt, pbkdf2 didn't exist. Or as if bcrypt has always existed and doesn't have any weakness
The weakest link, either in bcrypt or MD5 is the password quality.
Of course, in pure MD5 today you're a google search away and modern computers can eat salted MD5 for breakfast
But the easiest passwords are going to be broken first
So yeah, the weakest passwords will always fall, but good solutions will go to great length to protect even the most clueless of users.
If you use any reasonable cost for bcrypt, you're talking hundreds of milliseconds per attempt on a modern CPU. For each 6-character password (since you can't generate a rainbow table) at 100ms per pop, you're talking about something on the order of 2+ years per password divided by the number of CPUs. With something like 900 CPUs running continuously, you could expect to recover one 6-char every day if the passwords were randomly distributed in the 6-char alphanumeric space. So, pretty feasible, assuming a 100ms cost. Short passwords do hurt you; I agree.
Now for 8-char alphanumeric passwords, you'd have to run ~1 million CPUs continuously to expect to recover one per day at a 100ms-per-pop cost. This is more of a stretch, assuming you're trying to do this with, e.g., botnets. It seems that someone asking for help cracking a password list on a forum would probably not be able to assemble this much computing power.
Or 1 billion CPUs continuously to expect to recover one 10-char alphanumeric password per day.
Of course, the assumption of random alphanumerics is wrong, both because many people will use common passwords and because others will use non-alphanumeric character substitution.
At any rate, it seems to me that leaking non-salted SHA1 hashes is virtually the worst case disaster scenario, short of plaintext passwords.
But suppose tomorrow it takes 10ms. Also, tomorrow, available spaces will increase, so the likelihood of a space vs time tradeoff (even partial) increases
WEP was considered "good enough" at first (even though it had obvious problems at first like key size), WAP was considered unbreakable at first, today it's feasible with cloud computing or GPUs.
And then we'll be complaining on HN that they didn't use xyzcrypt or something instead of bcrypt.
" it seems to me that leaking non-salted SHA1 hashes is virtually the worst case disaster scenario"
Yes. Salt is password storage 101!
Sure, you can increase the work, but you'll still be limited by bcrypt size
Otherwise, you could just MD5 hash stuff X times and be done with it
Sure, bcrypt today is very safe, but I wouldn't be surprised if attacks are found today (even if they rely only on bruteforce)
And let's not forget implementation issues that may happen in specific bcrypt libraries
It's ok if WAP is breakable with cloud computing, because the whole point was to secure it for the next X years so that it takes more than Y dollars to break it. You only need to protect million dollar data enough that it costs 10 million dollars to get it.
If the data is valuable enough and protected heavily enough with crypto, the cheapest way to get it is through a meatspace attack (break-in, abduction, etc).
> WEP was considered "good enough"
Not by security professionals once they saw the effective size of the key. It's the downgrading of what looked like a 64bit key into a 48bit key that was the biggest problem.
(95^6 * .1sec per hash) / (60sec 60min 24hrs 365days)
The key difference is bcrypt does ~10 hash/sec. A GPU-enabled password cracking machine can do over 500 million hashes per second. That generates a rainbow table in ~30 minutes.
I just had to make this choice a few days ago and bcrypt seemed like the best option with working PHP implementations. And I sure as hell am not going to try to roll my own.
The #1 google response for info about Scrypt for php now points to an article arguing about the semantics of the question with no answer. Classic!
People are using unsalted SHA1, because someone told them in the past "just use sha1". Now someone else tells them "just use BCrypt". Without understanding why, it's nearly impossible to to decide which security policy is sensible. There are many different types of advice competing for attention, and not all of them are good.
The guy who said "phlogistons" was wrong. So was "just use SHA1" guy.
This additional slowdown is unlikely to be noticed by a user during an interactive login (hashing the password may take 1ms instead of 1us -- an imperceptible difference to a human) but it dramatically slows down the speed at which an attack can compute hashes to try and recover the password for a leaked hash. It also increases the amount of storage space required for (a naive implementation of) a rainbow table since the attacker would need to store the output for 1, 2, ..., n iterations of the hash function.
Of course, it does not mean you should take a slow implementation of a fast hash. You need a hash that, when implemented to be as fast as possible, still is pretty slow.
Edit: they are salted though.