Limit password entropy calculation using zxcvbn to 128 characters #7748
Conversation
|
I'd prefer to not make this asynchronous, just limit the use of zxcvbn to 128 characters and use simple log estimation after that. AsyncTask has the nasty side effect of compounding the stack because it creates an event loop on top of an event loop. |
libklein
force-pushed
the
feature/async-password-entropy-check
branch
from
77531b8
to
776bd8f
Compare
Codecov Report
@@ Coverage Diff @@
## develop #7748 +/- ##
========================================
Coverage 64.29% 64.29%
========================================
Files 339 339
Lines 43431 43437 +6
========================================
+ Hits 27923 27927 +4
- Misses 15508 15510 +2
Continue to review full report at Codecov.
|
droidmonkey
changed the title
droidmonkey
changed the title
libklein
force-pushed
the
feature/async-password-entropy-check
branch
from
6788a67
to
fd17468
Compare
droidmonkey
force-pushed
the
feature/async-password-entropy-check
branch
from
fd17468
to
9720030
Compare
|
I basically rewrote this entire PR. Instead of just changing this in the password generator, I changed it at the source of Zxcvbn usage, PasswordHealth. This has the positive benefit of reducing CPU usage no matter where we calculate entropy! Additionally, I upped the limit to 256 bytes, removed the chunked calculation, and replaced it with a byte-average calculation (when > 256 bytes). The results are within a 1-2% difference from pure zxcvbn calcs in my testing:
|
There was a problem hiding this comment.
To be honest, IMHO it's probably a waste of resources to provide an estimate for password beyond 256 characters, so i think that the modifications are fine as it (except the byte split thing). To play the devil's advocate, here are some concerns regardless:
How did you measure the average error? ZXCVBN is pretty sophisticated and the runtime/entropy estimation depends very much on the format of the password. It somewhat suprises me that there is so little difference between estimations.
See https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/wheeler.
I did not modify PasswordHealth directly as i figured there may be cases (say for database audits) where we want an accurate estimate of password strength. Perhaps this should be an alternative implementation of the PasswordHealth interface?
src/core/PasswordHealth.cpp
Outdated
| { | ||
| auto entropy = 0.0; | ||
| auto pwdBytes = pwd.toUtf8(); | ||
| entropy += ZxcvbnMatch(pwdBytes.left(ZXCVBN_ESTIMATE_THRESHOLD), nullptr, nullptr); |
There was a problem hiding this comment.
Will this work with multi-byte UTF-8 chars? Maybe it's better to split based on character count and not on bytes.
There was a problem hiding this comment.
Technically you'd only have multibyte unicode characters if you pasted them into the password field. We don't support generating passwords with unicode. But yes, we can do the limit check on the string, then convert it to utf8 bytes for zxcvbn.
|
The error is irrelevant for any meaningful analysis. It also remains small if the remaining bytes in the string have the same amount of entropy. If you have a non random first 256 bytes and a random remaining you'd see the most divergence (and vice versa). However, at that point you are overflowing hash algorithms and your password, no matter its randomness, is equivalent to guess the hash itself. Plus we bin your passwords by rating, excellent is reached well before you hit 256 bytes. |
Limit the use of zxcvbn based password entropy estimation to 256 bytes. After this threshold, the average per-byte entropy from the zxcvbn calculation is added for each additional byte. In practice, this produces a slightly higher entropy calculation for purely randomized passwords than zxcvbn would normally calculate. However, the time to calculate is capped leading to a much better user experience and removing unnecessary calculations. Fixes keepassxreboot#7712
droidmonkey
force-pushed
the
feature/async-password-entropy-check
branch
from
9720030
to
92928f5
Compare
Fixes #7712.
Essentially changes the behavior of password strength updates in two ways:
Testing strategy
Refactored existing tests and added new ones checking an exceedingly long password.
Type of change
Discussion
Issues