Slashdot Mirror

That was more a comment on typical human nature which results in people choosing dictionary based passwords.

Also, it depends on the cost factor as well, obviously. I don't recall seeing an indication of what it was.

Either way, it would be fairly reasonable to try, say, the top 30000 common dictionary passwords (and other common passwords) on each hash in the table. According to http://openwall.info/wiki/john..., you can do about 1000 bcrypt hashes per second on a single core of an i7 3k series. So you can try all 30000 dictionary passwords in 30 seconds on a single core. If you ran say, 1 million passwords, it would take 30 million seconds, which is 347 days. Now if you can rent a single of these cores for say, $25 a month (which I think is conservative but it's hard to find cloud compute based on a specific processor), you would need 12 of them for a month, which would cost $300.

Magnified by my suspicion (completely not based on any scientific study) that:
People with weaker passwords that would be found using the dictionary attack are:
  - More likely to reuse their passwords elsewhere
  - Less likely to pay attention to news like this
  - Less likely to actually change their password other places if they do find out about this

you will have at least some payoff.

It depends on the hash. If you assume there are 1 billion phone numbers (which isn't so different from 10 billion), a decent CPU would still be likely to crack a weaker hash in a few seconds.

Even somewhat stronger hashes would go fast, John the Ripper does 20 million checks per second on DES Crypt:

http://openwall.info/wiki/john/benchmarks

So it would take a couple of minutes to crack that.

(the problem is that there are only 10 digits; if you have ~40 characters to choose from, there are more than 1 billion passwords with 6 characters)

Matt -

I have so many comments on what you wrote that I don't dare to post them. :-) But I'll say a few things:

Password policies still make sense to me when combined with modern (salted and stretched) password hashes, particularly for large user databases where each account is of relatively little value (your Sony example applies here). Rather than absolutely require certain character classes, users should also be given the option to use longer passphrases, where the number of required character classes can be reduced to 2. I think you have our passwdqc in DragonFly (via FreeBSD), right? Well, it includes passphrase support by default, starting with 3 words of combined length 11, including separator characters - or longer, indeed.

Thank you for describing your authentication methods policy for developers. We use a similar policy for multi-developer or multi-sysadmin projects: http://openwall.info/wiki/internal/ssh

- Alexander

And I talk about the old style 8 chars max unix hashes.
See some stats here:
http://openwall.info/wiki/john/benchmarks#Collected-john-test-benchmarks-for-one-CPU-core

and cracking the newest sha512 takes how long?

ighashgpu bruteforces Windows NTLM password hashes at a rate of 2.4 billion password/sec on a single GPU (HD 5870). What does this mean with respect to TFA and its measly "4 million/sec"?

Many of the discussions here completely miss the point that bruteforcing rates depend entirely on what is being bruteforced. For example if you look at JtR password hash bruteforcing benchmarks you can see rates with a Core i7 920 anywhere between a measly 758 password/sec (bcrypt) up to 14.6 million password/sec (LanMan). This spans 5 orders of magnitude! It's the same for encrypted files. For example PGP files encrypted with a symetric key issued from the Simple S2K mechanism can be bruteforced at millions of password/sec with a regular CPU, but this can drop to only a handful of password/sec if Iterated+Salted S2K was used with a decent S2K count...

Therefore all these discussions about whether "4 million/sec" is good/bad/improbable are completely irrelevant since the article is devoid of any info about what is being bruteforced.

Not true. Unix passwords are never decrypted.

The parent is, of course, referring to one way hashing (crypt, MD5, SHA-1, and the like). Unix passwords were originally stored in the /etc/passwd file for all the world to see—any user could open the file and see everyone's password hashes.

One-way hashes keep systems secure by virtue of computational complexity: an attacker must blindly try passwords (either by brute force or word list) until he finds the one that produces the correct hash. However, there are many different possible passwords. How many? If users use no more than eight letters or numbers, the total number of possible passwords is the sum from i=0 to 8 of (26+26+10)^i = 2.2192 * 10^14. Even at 10 million checks per second, it would take 256 days to check them all.

Unfortunately, I've never seen a bank that allows you any more (or less) than four digit PINs, which is only 10^4 = 1000 combinations. This makes one-way hashes less than useless for encrypted PINs: Anyone who knows how to compute the hash and possesses a list of hashed PINs could easily crack PIN numbers very, very quickly.