3 ms·
On average, the attacker will have to search half of the hash space to find a given password. So, your 40,000 searches is way too small as long as you require
by decode 17y ago
On average, the attacker will have to search half of the hash space to find a given password. So, your 40,000 searches is way too small as long as you require more than 2 character passwords. If you assume lowercase + uppercase + numbers for the passwords, and require at least 6 characters, you get
(26 + 26 + 10) ^ 6 = 56,800,235,584 combinations
searching half of that would be about 28 billion combinations. At 50ms each, that would take 388,888 hours, or 44.36 years.
- lsc 17y agoif passwords are randomly generated, I agree with you completely, and everything I've said is crazy talk. But most passwords are not randomly generated. Most passwords are dictionary words, or two dictionary words. You don't need to search the hash space; you only need to search the password space, and if everyone uses the name of their dog, well, that's not a very large space. http://www.schneier.com/blog/archives/2006/12/realworld_passw.html http://www.schneier.com/blog/archives/2006/12/realworld_pass...
- tptacek 17y agoIf passwords are two dictionary words, then even with the system dictionary, a single 50ms hash takes 889,251 hours to crack. 8 million if people put a single digit at the end of it. You won't win this argument.
- lsc 17y agoadding two dictionary words and a number, yeah, that helps a lot. looks like you are right, and that if your users use 2 words and a number, and you use a hash that takes 50ms to calculate, you are probably OK. but my point is that passwords are a lot less secure than they sound if you just add up the characters. And most hash functions take a whole lot less than 50ms of cpu time to calculate. Bcrypt does look pretty cool in it's ability to slow down brute force attacks. It does still require a minimum amount of entropy in the user passwords, though.