Given Diceware, why does the requirement to contain uppercase, numerics & punctuation in passwords still stand?

Question

Example strong diceware password:

widow stout harvey crest zomba zloty butyl

This password will be rejected by most sites, for example by Outlook.com. (Notable exceptions: Gmail, Stackoverflow, which seem to accept this very password (tested))

Example modified diceware password that will be accepted by most sites:

Widow stout harvey crest zomba zloty butyl1.

Is this password much stronger than the original one? I doubt.

Example password that will be accepted by most sites (checked on Outlook, which rejected the orignal password):

zxcvPOIU

This password seems to me to be substantially weaker than the one that was originally rejected!!

And yet - in my experience this is what most sites still require.

Given that most does not include Google nor Stackoverflow - is this requirement simply outdated, but most sites still did not catch up? Or are there any actual reasons why lowercase/uppercase/numeric/punctuation is still to be required?

Answer 1

First of all, there are different criteria on what is a good password.

Facebook will happily let you in using a password with reversed case. Others will frown at that. A few years ago, Outlook.com wouldn't have let you use a password with more than 16 characters. Each site may have different password policy, which leads to different implementations. Some sites require symbols, other consider that a long-enough password is enough.

The main problem, however, is that the site doesn't know how the password was generated. A diceware-generated "widow stout harvey crest zomba zloty butyl" has about 90 bits of entropy. Whereas "this is my password for stack exchange" would have much less (specially if I know you used "this is my password for outlook.com" at outlook!).

Thus, password meters (such as the validations embedded in those sites) resort to estimating the entroppy of the passwords. Generally, adding capital letters or symbols increases the password space, so it was commonly recommended (or required) that lowercase, uppercase and symbols were present in the password as a proxy to "the password will be hard to crack". This is reinforced by common suggestions to do that.

You will find that usually, when the system can generate a password for you (such as access tokens), it doesn't require all that). Since the password is generated by the server it knows how it is generating it and thet it has enough entropy.

Finally, note that in some systems there may be actual reasons for requiring certain length or types of characters. Mainly because they are used (copied) into systems that require it, or because of regulatory reasons, they need to require that, even if it is not that important.

Answer 2

Simply put, because it increases entropy.

The word widow could be written in the following ways:

• widow
• Widow
• wid0w
• w1dow
• w!d0W
• ...

You might argue that a simple rule in hashcat would include all those examples, and you would be right, but it still increases cracking time, as any feasible combination would need to be included.

If an attacker could make the reasonable expectation that the vast majority of passwords would only consist of lowercase letters now, then cracking time could be sped up significantly by just removing most permutations.

That's why mixing and matching case is still solid advice. For instance, you could capitalize the second letter in every word, and get

wIdow sTout hArvey cRest zOmba zLoty bUtyl

An attacker who only picked the rules examplified above would not crack this diceware password, even if they knew all the components of it and their order.

Answer 3

I'd argue it shouldn't stand, as diceware passwords generating from a secure source of entropy (like physical dice or secure random numbers) can have plenty of entropy. Unfortunately, a lot of existing software operates on the assumption that the user doesn't understand entropy, so stakeholders feel it's necessary to introduce additional entropy by enforcing a specific type of password (see the monkey problem as mentioned by @AndrolGenhald).

Overall, I personally feel it's best to not implement any password restrictions other than comparing against breached passwords and requiring a minimum length that isn't too short, as to not discourage secure password generators such as diceware. If you're concerned about users not having enough entropy on their passwords, you can generate one from a securely random source, use an alternative authentication mechanism like a passkey, or recommend a password manager.