Browser unresponsive for long passwords (WordPress)

[BevanR]

WordPress has an issue where if a long password (500+ characters) is checked for password strength, the browser becomes unresponsive for many seconds or minutes: See issue #31772 for the details.

Possible solutions

1. Use Web Workers to do the strength checking
   • Would this be a welcome contribution?
2. Enhance axcvbn to stop checking strength once a specified threshold of entropy is reached.
   • What would the default threshold be?
3. Only use zxcvbn if the password is more than 32 characters long
   • The problem with this is that weak passwords can be longer than 32 characters. E.g. 33 zeroes: 000000000000000000000000000000000
4. Only use zxcvbn on the first 32 characters
   • Would this make zxcvbn less effective?
5. Improve the performance of the strength-checking for longer passwords
   • Is this even possible without significantly impacting its accuracy?

[jomo]

I'm also having this issue (on Slack)

[BevanR]

@ChicagoSchooler; Are you saying that a solution that does not check passwords more than N characters long is a good solution? If so, what is a suitable threshold value for N?

[BevanR]

@ChicagoSchooler; Thank you for response. I think I understood most of it. Unfortunately it does not seem to answer any of the questions in the original post. (I agree it is a WP problem. That is not the question.)

[jomo]

The browser being unresponsive for long passwords is due to zxcvbn blocking until calculation is done, which is a problem with zxcvbn, not WordPress.

[BevanR]

Using Web Workers is a great idea. Thank you @ChicagoSchooler! 👍

Is this a feature that could be built into zxcvbn? Would the maintainers like such a feature?

Would you mind elaborating how using zxcvbn only on the first 32 characters would make it less effective?

I understand that it is pointless for serious passwords. zxcvbn currently works well for both serious and not-serious passwords, reflecting the strength of each. Is that likely to change?

[BevanR]

Thanks @ChicagoSchooler.

I would be interested in the opinion of the maintainer about whether a Web Workers feature would be a welcome contribution.

Another idea occurred to me; What if zxcvbn stopped checking more characters after a sufficiently high entropy was reached? In otherwords, set a threshold of an entropy level instead of a character limit. (Though I still think Web Workers is probably a better solution.)

[lowe]

Hey @BevanR , maintainer here. Unfortunately I haven't been able to dedicate much time to zxcvbn upkeep (planning to make some improvements soon when I can dedicate a larger block of time -- stay tuned!).

In terms of whether it's a reasonable ask for zxcvbn to process a 500-char password efficiently -- absolutely! I'll keep it on my list of things to do, and will be thinking about simpler ways to give good but efficient strength estimation for longer passwords.

Using Web Workers seems like overkill to me at first glance -- zxcvbn is meant to give immediate, preferably sub-perceptive feedback. It seems to me a sufficient solution is to speed up the core function for long inputs.

In the meantime I'd use a simple workaround -- only passing say the first ~50-75 characters to zxcvbn would eliminate your efficiency concern and only yield inaccuracies in rare corners (eg first 75+ characters are a simple repeat, the rest is more complex.) Also note that only evaluating the first 75 chars will except in extremely rare corner cases never overestimate the entropy*, just underestimate -- this could erroneously send the message "you need a better password" when in fact the megapassword has plenty of complexity in its suffix, but it won't incorrectly tell the user that their password is great, which I consider worse.

* only exception i can think of is a long dictionary word that ends somewhere after the 75-char boundary, a tiny corner case.

[BevanR]

Thank you for your thoughts @lowe.

How to you determine a threshold of 50-75 characters? What are the benefits (for WP) of lowering or raising this threshold?

The longest words likely to be found in any normal English dictionary are all much less than 75 characters. See Longest word in English on Wikipedia

As for other languages, this Wikipedia article on Longest words documents quite well that languages known to have longer words are all compound words with many components. Such words would not be found in any regular dictionary for those languages.

The only exceptions are Icelandic and Maori which have place names that are 64 characters 85 characters long respectively. I think these exceptions are so few for a threshold of around 70 characters that they are probably acceptable. WDYT?

[lowe]

Hey @BevanR ,

The threshold should be determined by what sort of performance bound you're looking for. I think 75 is the right ballpark, you'd probably be fine at 100 as well.

On my 2.6 GHz Intel Core i7 running the latest version of Chrome, zxcvbn takes around ~15 milliseconds for 75-char base 62 strings. Anything under 100 ms is totally acceptable imo -- what I don't know is how slowly zxcvbn runs on other setups...someone please let me know what OS/CPU/browser if they observe 100ms+ runtimes for 75-char inputs.

To get a quick ballpark you can try running in your browser console:

var start = new Date().getTime();

zxcvbn('zRqeSxuyg9pnMHCkV{iktT,pCdE7scUcjcLQnLmqLm#VtHLKYb,pCdE7scUcjcLQnLmqLmCVtHL');

var end = new Date().getTime();
end - start; // milliseconds

re: Maori -- I wouldn't worry about these corner cases unless you've seen cracker lists that check against them or better yet cracked passwords that include them. Not likely in the case of 85-char Maori place names!

[lowe]

ps. while not the greatest password, "taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu" would be a fantastic user name. distinctive, memorable!

[BevanR]

Great! Thanks @lowe. I will suggest WP moves forward with a solution that only inspects the first ~75 characters for now.

On Chrome on Mac OS X 10.8.5 with 1.3GHz i5 I got 25-40ms for that test script.

[BevanR]

I submitted a patch to the WP core issue queue that limits the strength check to the first 128 characters. (FYI only.)

[lowe]

Thanks @BevanR , closing this out.

[jomo]

@lowe has this issue actually been fixed?
I'm still getting this error in Firefox:

Warning: Unresponsive script
A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.

Script: zxcvbn:2

[lowe]

Hi @jomo, are you reproducing this according to WP issue 31772?? Or do you have other steps?

I closed this issue thinking every user of zxcvbn will have their own performance bounds, therefore it shouldn't be the lib's responsibility to automatically cut off after N characters, let clients (eg wordpress) do that.

But given zxcvbn runs well on ~100-200 characters, more than the vast majority of passwords, it'd be reasonable to add a cutoff inside the lib. Let me sleep on it.

[jomo]

Nothing related to WP.

zxcvbn runs well on ~100-200 characters

I just tried the latest version with a 200 character password. It made Firefox hang for a couple seconds and then:

My password manager has a slider going up to 256 characters, I just use that (because why not?).
I've been very annoyed on sites that use zxcvbn due to FF being unresponsive for a long time.

How about cutting passwords off at 100 characters by default, but allow changing that?
I think 100 characters is a good limit because I had ~500ms of calc time in FF, which is acceptable.

e.g.:

zxcvbn("secret");                // use default of 100 characters
zxcvbn("secret", {limit: null}); // unlimited
zxcvbn("secret", {limit: 256});  // 256 characters

[tracker1]

Would it be possible to run for each 64characters, overlapping at 32... so first would be 0-63, then 32-95, 64-127, etc.. stopping at whatever feels good, would think getting the first 128 characters in 4 passes may be more efficient than trying to get it all in one.

Alternatively, NIST's new guidelines suggest if you have a password limit, it be at least 64 characters, so maybe advising users to trim/limit at 128, and use that in any case may be a good idea.