zxcvbn4j
zxcvbn4j copied to clipboard
Slow compute times on long passwords
When using Zxcvbn.measure( password ) for lengthy values of password, the evaluation time can be longer than (my) expectations. In my case with a password consisting of the value 'a' repeated for the following lengths:
password length: 1000 calc time (ms): 3158
password length: 2000 calc time (ms): 17286
password length: 3000 calc time (ms): 56919
password length: 4000 calc time (ms): 133593
The time seems to be increasing non-linearly. At worst, I would expect that lengthy inputs would be truncated before being evaluated to prevent denial-of-service attacks.
Non-linear execution time is to be expected due to the need to detect repeating patterns.
It feels to me that this kind of DOS protection should be implemented in the application, not the library.
For the kinds of user passwords that you'd want to check with zxcvbn4j, you really aren't likely to have anything anywhere near a thousand characters. The only likely candidates for really long passwords are those from password generators, and they can generate really strong passwords in well under that limit.
So, in my opinion, this should be a WONTFIX. If you are worried about DOS then just limit the password length to a few hundred characters.
@SteveLeach-Keytree I was under the same impression for a while for my version (nbvcxz), but eventually decided to implement a maxLength configuration, that would truncate the password to an appropriate length and do comparisons on that part of the password. For example, bcrypt only allows 72 characters, anything extra isn't actually taken into account for hashing/comparison. So using the "full" password for estimation isn't really useful.
Anyways here is my commit for implementing this if interested: https://github.com/GoSimpleLLC/nbvcxz/commit/c387d5434de377089f6f2aa417cb6dd82ec0e915
So, in my opinion, this should be a WONTFIX. If you are worried about DOS then just limit the password length to a few hundred characters.
I agree with this opinion.