search

dropbox / zxcvbn

Low-Budget Password Strength Estimation
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/wheeler
MIT License
14.98k stars 931 forks source link

Bruteforce entropy estimator does not account for cardinality #264

Open espadrine opened 4 years ago

espadrine commented 4 years ago

The output of </dev/urandom tr -dc a-f | head -c 12 (eg. beaddbddabba) yields a guesses_log10 of 12 (4/4, 3 years slow hash offline attack), when the entropy source can only deliver a guesses_log10 of log10(6)×12 = 9.3 (3/4, 4 days slow hash offline attack).

Could we instead compute the minimum between cardinality 10 and the cardinality actually found in the bruteforce section? It would help people that overestimate the keyboard-mashing approach to password generation. I would be happy to implement it if you agreed to the design.

(The ideal solution would be https://github.com/dropbox/zxcvbn/issues/234#issuecomment-531579336, but that would be more subtle to implement.)

(I also notice that zxcvbn significantly underestimates the strength of generators like </dev/urandom tr -dc [:alnum:], but from my reading of #17, this is on purpose.)

laughinghan commented 4 years ago

Do people really generate passwords by keyboard-mashing? How do they memorize it then? (Or do they then write it down on a Post-it or in a passwords.txt file on their desktop?)

espadrine commented 4 years ago

It’s more of a ”time to generate a REALLY random password!” kind of thing.

It’s better than them trying to come up with randomness out of their head (humans are terrible at it, for instance they will have too few instant repetitions), which I’ve also seen.

But it is worse than rolling a dice (which is also not quite random), or using ChaCha20 seeded by interrupt timings and jitter entropy.

antibarbie commented 5 months ago

I second this.

I also have a funny scenario : govenment agencies policies require that users have a minimum entropy that's pretty high : e.g. ~ 88 bits or 109 bits. But since ZX overly underestimates random brute force passwords, "good passwords" (for example coming from password managers) are not estimated at their actual strength. So either we lower the bar of required "guesses" in zxcvbn, and gov agencies will frown at us, either we keep the bar high, and people will need to type passwords of higher complexity than actually required (WAY higher than required).