undefined | Better HN

0 pointsdecode17y ago0 comments

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.

0 comments

3 comments · 1 top-level

lsc17y ago· 2 in thread

if 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_pass...

tptacek17y ago

If 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.

lsc17y ago

adding 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.

j / k navigate · click thread line to collapse