Increase the minimum required entropy before we warn

[bknowles]

Okay, so I've done a bit more digging, and I think we need to update the math that is being referenced.

Currently, oclHashCat (see http://hashcat.net/oclhashcat/) can do about 42408 Mh/s when cracking SHA-1 password hashes, on a single computer with multiple GPU cards. Note that Mh/s is Million Hashes per Second.

So, if we have only 52 bits of entropy (which is the current default before we warn), that would take 4503599627370496 / 42408000000 = 106196.935 seconds to brute-force the entire space. That's less than 30 minutes. And cracked on a single machine, assuming a hashing algorithm that isn't too excessively old.

We could reduce that by an order of magnitude, if we could make the assumption that everyone was forced to use SHA-3 instead of SHA-1, because we would be reducing the speed to 5240 Mh/s.

But this still wouldn't be taking into account speed improvements through parallelization (e.g., running on EC2's GPGPU cluster).

Maybe we should tell people how many bits of seen entropy that are being generated, and how fast those passwords could be cracked, using a few different assumptions for speed?

[bknowles]

Oh, and Randall's minimum of 44 bits of entropy could be cracked in 17592186044416 / 42408000000 = 414.83 seconds.

Oy.

[bbusschots]

I'm very much in two minds about raising the seen entropy threshold.

A few thoughts:

• the seen entropy is an absolute positively worst-case scenario where the attacker not only knows which module you used to generate your password, but what exact settings you used, and what exact dictionary you used. In reality it seems very unlikely all three of those things will be true, so realistically, the attacker will have a lot more permutations to try.
• I chose 52 bits because it's equivalent to an 8 character password, still in line with a lot of password advice (at least for now) - if all hell breaks loose and an attacker knows exactly how you generate your passwords as described above, still having the equivalent of a truly random 8 character password in that extreme scenario seems quite good.
• If I raise it, and it starts warning people too soon, it may put people off what are actually very strong passwords in realistic situations, and drive them back to much worse practices they had before.
• If I raise it, what do I raise it to?

(I made the thresholds configurable, so those who want higher thresholds can configure them as they desire - this can be done in the config file BTW)

I don't have a firm opinion on this, so I'm open to persuasion.

As for adding in cracking times, I can see why it would be appealing, but, it's something I'm just not comfortable doing. For a start, no matter how I calculate them, someone will be on here telling me I'm wrong. Secondly, cracking times are guestimates at best, and the code will constantly need to be updated to reflect new developments. I don't think I want to maintain that kind of code.

The reason I chose entropy and permutations as my stats is that those are measurable quantities. There is no guesswork there, and the number will never change. Those who want to estimate cracking times can use the permutations count and current estimates of cracking speed to get their answer.

[bknowles]

I always assume worst-case, that the attacker knows exactly which dictionary you used and what settings you used. They just presumably don't know the specific password/phrase entry that you selected from the list that was generated. That's why I like having you provide the "seen entropy", because that is my worst case right there. Even if we don't change the defaults for warning or anything, it would be nice to have the entropy information output by default in all cases, so that people could judge for themselves how far they might want/need to go.

Or, if not output by default in all cases, then give me a configurable option I can set to get that behaviour, and then a good sample configuration file that I could put into my home directory that would automatically get used, if present.

[bknowles]

As for cracking times, I was assuming we might see a high/medium/low spread, based on configurable defaults. The default might be to not display this information at all, or not display it if the configured speeds are set to zero. Then users could set their own configured hashing speeds, in their configuration file.