Has 'time to crack' gotten shorter with more GPUs?

[VWFeature]

The Ars Technica article http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/2/ said that they quickly bruteforced all passwords of 6 or less, plus the all-upper or all-lower passwords of length 7 or 8 in just 41 seconds.
Yet the 'crack time (display):' for an all caps 7 char password is 5 years. I suspect more GPU power has made cracking faster.

[pyramids]

In part, this is a cardinality bug in the brute force pattern (59, whilst all-uppercase presumably means there are only 26 to choose from). On a fork that uses 26 as cardinality for such cases, I get an estimate of 6 days.

The rest depends on settings that comments in the code suggests the original author expected users to change in the library source code anyways. In a fork I'm currently working on, I'm making those configurable. But I don't think it is a good idea to change the defaults since there is the possibility that some legacy code somehow breaks rather than just moving to more 2014-ish cracktime estimates.

All that said, my gut feeling is that even just including a crack time estimate into the library was a poor design decision in the first place---the calculation from an entropy estimate is trivial yet entirely dependent on your choice of hashing function and your assumptions about attackers' capabilities. There's simply nearly nothing that actually has a place in a library rather than in the custom code using it.

[VWFeature]

I still think a 'crack time' estimate is useful for less technical users like me, even if flawed, as long as we understand its potential shortcomings. Another password strength estimator, Passfault, http://www.passfault.com/password_strength.html#menu allows users to set some of the cracking variables you mention, specifically the strength of the hash, ranging from NT Lan Manager, to SHA512, SHA512 hashed 100k, to BCrypt, and the strength of the cracking computer, from an 'everyday computer', to a $500,000 government level cracker.

I think we all should understand that it's all a question of how good the crackers' "password pieces" dictionary and combinatorial algorithms are, vs the password creator's algorithm, unless we're using true strong pseudorandom passwords we have to write down. Like any other defense/offense situation, it's an evolving process. As not_quite_good_enough passwords get cracked and added to the corpus of known passwords, mediocre passwords get more compromised.
Note of course that even in the mass of leaked passwords, there were a few that resisted cracking.

[kimmobrunfeldt]

Related to https://github.com/dropbox/zxcvbn/issues/58

[VWFeature]

Re kimmobrunfeldt's comment that the crack times depend on the site using bcrypt, scrypt or PBKDF2, rather than MD5 or SHA512, yes, exactly. Far too many sites rely on 'keeping the password list safe' rather than encryption science. For all I know there are still folks out there keeping username/passwords in clear. (Of course, then no pw is safe- a reason to avoid password reuse except on trivial sites.) And large scale password cracking depends on stealing password (hash) files from sites, which is obviously feasible (Adobe, RockYou!, EBay, Ubisoft, J P Morgan, etc., etc..)

IF zxcvbn felt like adding the feature, you could emulate Passfault to specify hashing and machine resources ("Government Cracker, $500,000 machine), or better yet, combine word lists and fragments w Passfault to better simulate crackers' resources. If you remove the 'time to crack', that could be replaced by a text table with the data- seems it should be about as easy to change 'time to crack' programmatically, but I don't know the code.

The take-home message is this: better passwords are: longer, contain more kinds of entropy, longer, generated by a pseudorandom process rather than pulling trivia from one's past life or popular culture, longer, contain more kinds of characters, longer, a mix of patterns or broken patterns, longer, kept track of by password keeper software such as Keepass, longer, not reused, and longer. (See a pattern here?) RIght now, pseudorandom lower case sequences of >12 are resistant to cracking/hit the computational wall, but Moore's Law means eventually we'll have crackers with 10^6 GPUs. Password security is a moving target.

http://keepass.info/plugins.html#propwgen http://www.passfault.com/password_strength.html?#menu http://readablepassphrase.codeplex.com/ http://www.watter.com/Default.aspx?tabid=821 (Random Shakespeare password passphrase generator)

[VWFeature]

Could also be made stronger by just comparing to the list of 10,000 most common passwords: https://xato.net/passwords/more-top-worst-passwords/#.VFaYGfn9zOV

[moderndeveloperllc]

@VWFeature If you check the code, he IS using that list - https://github.com/dropbox/zxcvbn/blob/master/data/common_passwords.txt

[MrSchism]

For all I know there are still folks out there keeping username/passwords in clear.

http://plaintextoffenders.com/

It's worth noting that Pearson (a company that sells textbooks about information security) is on that list.

[lowe]

Closing this out for now, but it's on my roadmap to remove password storage assumptions + cracking hardware assumptions from zxcvbn scoring, such that a hardware-independent guessability estimate is emitted instead. See #58 for more discussion.