4

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?

gaazkam
  • 5,657
  • 11
  • 24
  • 38
  • 1
    There are some standards, such as PCI-DSS, that explicitly require passwords with multiple character classes (a-z, A-Z, 0-9, other _printable_ symbols (including multibyte characters) are considered distinct character classes in this context), and have released updates to these standards maintaining that requirement even after the NIST standards _explicitly_ state not to _require_ (but to allow unrestricted use of) multiple character classes. Thus, it becomes a case where security teams must do risk assessments and pick a standard. – Ghedipunk Sep 25 '19 at 18:26
  • 3
    This sounds like a [monkey problem](https://security.stackexchange.com/a/33471) to me. – AndrolGenhald Sep 25 '19 at 19:47

3 Answers3

3

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.

Ángel
  • 18,188
  • 3
  • 26
  • 63
-1

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.

  • 2
    I don't think this answers the core of the question: Yes, using character from multiple classes increases the search space and is great for users... but I interpret the question as, why do site owners still require multiple classes, when there are (seemingly) more effective ways to increase a password's entropy? – Ghedipunk Sep 25 '19 at 18:29
  • @Ghedipunk I think the answer to that question is honestly "Because everybody else is doing it." AndrolGenhald's comment describes it best. But "Does it make sense to have multiple character classes?" is still a very closely related question. I honestly don't know if I should delete the answer or not. –  Sep 25 '19 at 20:57
  • Don't get me wrong, this is good information. I'm at a loss to come up with an answer to the core of this question, other than my comment which boils down to "because certain very influential standards, which I don't like, say to do that." (I also wouldn't recommend a diceware password; I'm a full evangelist of using password managers with long, unique, random passwords for each account on each site, but that's not what this question is about, either.) – Ghedipunk Sep 25 '19 at 21:09
  • @Ghedipunk But what do you use to secure that password manager database? Or in my case, my os login, before the password manager is available? –  Sep 25 '19 at 21:27
  • I tell my users to try to remember only two passwords: The one to log in to your computer, and the one to open your password manager. Since they're the only ones that have to be remembered, they can be very complex (and leet-sp34k modified) Correct Horse Battery Staple passwords... (or to follow your example, cOrr3ct hOrs3 bAtt3ry sT4p!3.) I also point out to my users that this is good in principle, but that I can follow it in practice only about 95% despite best efforts... The other annoyance with password managers is going to conference room computers... I write the PW on note cards. – Ghedipunk Sep 25 '19 at 21:35
  • 1
    @Ghedipunk: I wouldn't recommend leetspeak modified passwords for passwords manager and computer login. Just user plain diceware. Adding leetspeek transformation disproportionately makes the password much harder to remember and type, while not significantly making it more difficult for attacker. Diceware password is just not going to get brute forced. I recommend just adding an extra word instead to get much better security with less extra difficulty. – Lie Ryan Sep 26 '19 at 00:02
  • "Now was the first 'w' in 'widow' lower or uppercase? Was the second letter an 'i', 'I', '1', or a '!'? Was it 'd' or 'D'? 'O', 'o', or '0'? ..." Your average users will maybe add 1 bit of security per character. Now they have extra opportunities to mis-remember something at every character of their password. For a short passphrase, they could have gotten more entropy by instead adding an extra word. Humans memory makes it easier to memorize (and type) a few extra simple words compared to memorizing one of more than 2^32 variations on one simple base-word. – Future Security Sep 26 '19 at 20:27
  • Diceware passwords are secure no matter what characters they involve because of the amount of entropy they use. Adding additional modifications isn't necessary as long as you have enough words from Diceware. Also even if you capitalized the second letter of each word of a password, you could still crack it using a modified or masked dictionary, if it was low entropy (which Diceware is not, if you use it correctly). – Nick McCurdy Jan 06 '23 at 02:14
-1

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.

Nick McCurdy
  • 107
  • 3