The password requirements are bad

[fresheneesz]

The android app asks for a password that is at least 12 characters long, contains an upper case and lower case letter, and a special character. These are the ultra-common password requirements (plus a longer length requirement) and they are pretty bad advice for a strong password. Easy to forget, easy to guess, all around bad.

Please remove all the requirements except for the length requirement. See also: https://xkcd.com/936/ . If you want to, link to somewhere that explains how to create a strong passphrase using 4 or 5 words.

[ArtemGr]

This issue of XKCD might be missing the dictionary attacks. Or maybe the thought-provoking and artistic goals are in the forefront here and not the actual security of plain English passwords.

[fresheneesz]

Nope. As discussed here, "XKCD assumes the attacker knows the user has generated a passphrase by choosing four of the most common (top 2,048 in this example) dictionary words at random. Even so, the passphrase contains more entropy than the password."

[ArtemGr]

That might still depend on the calculations I guess. The article you cite says that in a password with special characters there can be 94 variations per character, which gives us 94^12=475920314814253376475136 which seems like more entropy than, again from that article, four of top 2048 words 2048^4=17592186044416

Looking at http://ascii-table.com/ the number 94 seems reasonable. If we use a wider vocabulary of 20000 then 20000^4=160000000000000000 still doesn't beat the random password.

And a manually coined password phrase would be prone to statistical modelling attacks, e.g. it's not the same as a randomly generated seed phrase.

The article doesn't give precise calculations so it might be a bit of a hype.

Maybe we should clarify the entropy intent of the long passwords. If we want the randomly generated 94^12 passwords then we should also discourage the user from using plain English passwords, and we've been discussing this as one of the options IIRC. Another option might be to dynamically increase the required length of the password when we detect a plain English text there. If, on the other hand, 12 characters limit was set with plain English passwords in mind, then removing the special characters requirement might be but a small chink in the armor. Also it might make sense UI-wise to recommend and not enforce, leaving the decision to the user. If the user doesn't want security then they can decide to keep the password in plain text somewhere, pin it on a wall or scratch it on the cover of the mobile device, - enforcing special characters wouldn't save them from that.

cc @ca333

[fresheneesz]

94 variations per character

That is unlikely to be the case. As the XKCD comic discusses, the additional entropy gained by requiring capital letters, numbers, and special characters is usually extraordinarily limited because of human psychology (not combinatorics). The password Tr0ub4dor&3 is really a single word with common additions and substitutions, which is what you get when a normal person makes up a password. A capital first letter is the most likely way to add a capital only doubles the combinations. Same with substituting numbers for letters - only some letters have rememberable numerical or symbolic substitutions. 0 for o, 4 or @ or & for A, 1 for i or l, maybe 7 for T, $ for S. Since not all letters have substitutions the number of likely actual variations per character used is more like 27 on average, 53 for the first letter, and one or two ending characters that might be a number or symbol, which is like 40 possibilities. Even then, they're probably using a base word or two from their native language. Most people know less than 40,000 words and they'll try to find some word they think is cleverly uncommon.

So the entropy for an 11 character password created by a normal person is more like 40,000 times 40^2 for the two possible end numbers or symbols times maybe 2 per character to factor in common letter (and short sequences like 'ate' 'and' etc). So that's a couple orders of magnitude smaller than 2048^4. It's also a lot harder to remember your password with random substitutions, which is why so many people write their password on a sticky note - making it useless for casual physical access security.

If we want the randomly generated 94^12 passwords then we should also discourage the user from using plain English passwords

But we don't want that, because random passwords are much harder to remember as I mentioned above.

Another option might be to dynamically increase the required length of the password when we detect a plain English text there.

I like this idea.

Also it might make sense UI-wise to recommend and not enforce, leaving the decision to the user.

I'm also a big fan of letting the user choose for themselves. The only time I think it really might make sense to double check this stuff is for stuff that would really be a huge problem for a person - like financial accounts.

[ArtemGr]

On a related note, in our "wallet unlock" screen the password field does not currently allow to paste a password, which prevents the random passwords from being used via the password managers. The "view seed phrase" action doesn't have that limit, so it might be an accidental behavior on our part.