Are password complexity rules counterproductive?

Question

In creating a login for this site I chose a nondictionary password that would be extremely hard to guess, but easy to remember.

I was told that it did not meet complexity rules.

After several iterations of this, in frustration and just for the hell of it I tried 'Password1' -which was accepted.

Raises the question how many non-IT people do likewise when faced with this situation? Golf1? Mercedes1? Metallica1? Guessable if you know the guy? Yes.

At work we issue passwords rather than allowing users to set them. We use nonsense words. For example, artifubulist. There is software to generate such words. Such passwords are surprisingly easy to remember but presumably, very hard to bruteforce. Unfortunately, default password complexity rules on Microsoft servers prevent this simple but secure option being used. Unless of course you change the policy.

Thoughts on this welcome.

Answer 1

Password complexity rules are counterproductive -- for the most part.

Password complexity rules:

1. make users angry, and thus uncooperative and likely not to enforce password protection rules that only they can enforce;
2. incite user to choose creative workarounds to go past the password rules
3. are often grossly incomplete, and don't filter out some classic or soon-to-become-classic passwords which users find as workarounds, see point 2 above. For instance "Password1".

The only "reasonable" password complexity rule which I have encountered yet is a minimal password length. Requiring passwords to have at least 8 characters is not a hardship on users, it is understandable, and avoids passwords which are necessarily weak since they are in range of the most stupid of exhaustive searches.

Answer 2

On the one hand, the complexity rules are probably not good. On the other hand, your “nonsense words” may not be as complex as you think.

There is no “presumably” about ease of brute force: this can be measured. For a given attacker, the cost of a brute-force attack is the average number of attempts before finding a password. While you don't know your attacker, you can assume that he is smart and will build his attack around your password choice methods. (It's the smartest attackers you need to most defend against anyway.) What the attacker will definitely not know is the part that you pick at random for every password. The amount of randomness in a password is called entropy; it is the number of coins that are flipped to determine the password, expressed in bits. The entropy also measures the number of brute force attempts that a smart attacker will require: with n bits of entropy, there are 2ⁿ possible passwords, and the attacker will on average need to try half of that, 2^n-1.

Requiring punctuation, digits or uppercase letter is common, but it doesn't help security much. Just about every user who would have picked a dictionary word as a password capitalizes the first letter and adds a 1 at the end. People who crack passwords aren't stupid: they include this and other l33tspeak variations in their cracking dictionaries. All in all, this requirement may add one or two bits of entropy in practice. There are better ways to make memorable passwords with more entropy. This is illustrated in xkcd 936 and discussed on this site in XKCD #936: Short complex password, or long dictionary passphrase?

Rather than presuming the strength of your nonsense word generator, you should measure it. Figure out how it generates passwords, and more precisely what the total number of possible passwords is. We can't tell from a single example. If the generator alternates 5 random vowels (presumably a,e,i,o,u) with 20 random consonant groups proper(b,f,l,rt,st,…), that makes (5*20)⁵ = 10¹⁰ ≈ 2³³. Assuming your passwords are properly protected, that's plenty for online attacks and ok for offline attacks. (If you aren't using a sufficiently slow hash, 33 bits is peanuts.) If the password generator is combining fragments of words from a dictionary, the entropy may be a lot less.

If you aren't in a position to lift the password complexity rules, issue passwords that comply. Make studies to see if they can remember one capital letter and one digit per password; if they can't, always capitalize the first letter and put a trailing 1.

Answer 3

Yes. The mindset in 2018 is that password complexity rules are indeed counterproductive. Recent NIST June 2017 Digital Identity Guidelines (SP 800-63B) reflects this clearly. Highlights:

• 8 or more characters.
• Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.
• Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).
• When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised.

If higher security is needed, use multi-factor authentication.

Nonsense words are a good idea assuming its composition rules are sufficiently random. I would be wary solely relying on a generator since its algorithm could be used to assist in breaking your password - augmenting it with something short but only meaningful to you would go a long way.

=== 2020 January update ===

Just to hammer home the point, NIST updated their FAQs (1/8/2020):

Q-B06: Are password composition rules no longer recommended?

A-B06: SP 800-63B Section 5.1.1.2 paragraph 9 recommends against the use of composition rules (e.g., requiring lower-case, upper-case, digits, and/or special characters) for memorized secrets. These rules provide less benefit than might be expected because users tend to use predictable methods for satisfying these requirements when imposed (e.g., appending a ! to a memorized secret when required to use a special character). The frustration they often face may also cause them to focus on minimally satisfying the requirements rather than devising a memorable but complex secret. Instead, a blacklist of common passwords prevents subscribers from choosing very common values that would be particularly vulnerable, especially to an online attack.

Composition rules also inadvertently encourage people to use the same password across multiple systems since they often result in passwords that are difficult for people to memorize.

Answer 4

Some complexity rules are counterproductive.

Examples of less productive complexity rules:

• Must be between 16 and 17 characters long (too specific a length)
• Must contain at least 3 of the following - $%^& (too few special characters to choose from)
• Must contain one uppercase letter, one lowercase letter, no sequential or repeated characters, one number, and one punctuation mark (too specific)

Examples of "good" complexity rules:

• Must be longer than X characters (encourages longer passwords)
• Must contain at least one number (encourages some, but not excessive complexity)

The best solution for me was to use a password manager, which allows easy compliance with even the most ridiculous rules, yet I'll never "forget" anything.

This is a clear case of putting all your eggs into one basket, and then watching the basket like a hawk via CCTV, and surrounding the basket with guard tigers and landmines.

Answer 5

It is stupidly simple to get around most sets of independently-evaluatable password complexity rules; minimum length, case requirements, non-alpha character requirements. "Password1", unless your name happens to be Joe Password, will get past most rule systems because it's at least 8 characters long, with a capital and a number. It's also the first thing any crackbot will try.

The cardinal rule of any password complexity requirement is, the harder you make your system to use, the fewer people will use it. This goes way beyond password complexity rules, but as the login screen (and the user registration screen you usually link to from there) are the first real interaction by the user with your system, the more unpleasant it is, the less your users will want to deal with it, and with you. This is especially important if you're trying to "sell" your system to users as a product they didn't know they needed, or if there are a lot of alternatives to you in the marketplace (like an online forum). Users in that situation will very quickly say "screw it, I'm out", and you are unlikely every to get them back.

A few additional rules naturally follow. One is that you inform the user clearly and simply of the rules you have in place, before they type in anything. It's not a security problem for the complexity rules you enforce to be public knowledge, unless those rules actually decrease possible entropy of acceptable passwords (which rules like a maximum length can do), and your user will be far less frustrated at your system than he would be if he had to learn the rules by reverse-engineering.

Another rule is, don't deviate too much from rules users expect. Most users are smart enough to understand that minimum complexity is for their own good, and they also know that the bars most sites and applications set are of similar height (6-8 character minimum, a capital letter and number, can't contain any of a few obvious words like "password"). Enforcing ridiculously long and complicated passwords in excess of the implied standard (minimum 20 characters, at least two groups of at least 4 numbers each and at least 5 symbols) is just going to piss people off, even if you tell them up front.

The last meta-rule I'll state is, don't enforce a rule for its own sake. Never use a rule just because you saw another site or application do it, or even just because it's best practice. There are reasons behind best practices, but you should know and understand those reasons, including why they may not apply in your situation, before Scotch-taping together a security policy.

The ruleset I usually like is:

• Minimum length of 8 characters.
• Either mixed case, number or symbols.
• Can't be composed only of a dictionary word.
• Can't contain any part of your name, username or birthdate (if I know these things)
• Can't have a "banned password" be 50% or more of the password. Banned passwords include any that have ever appeared on SplashData's Top 25 list, including most of the greats like "Password", "letmein", "12345678" etc, as well as any string that is "interesting" in IT security ("correcthorsebatterystaple", "orpheanbeholderscrydoubt") and any password previously used and known to have been compromised. The full list would be relatively short and easily displayed to users via a link from the list of rules.

Answer 6

Try cracking that example password. See how long it takes. I bet you will be surprised.

I encourage the use of password management tools (LastPass, etc.), lengthy and complex passwords, and WRITING DOWN passwords (with qualifications described below).

Yes, people have been told for years never to write down their passwords. But the threat model has changed. Back when that advice originated (in the 70's afaik) the threat was people grabbing the post-it from under your keyboard. Now the bigger threat is cracking the hashes. So now my recommendation is make it complex, don't bother remembering it, write it down, and store the written down password in a secure location such as next to the other small green pieces of paper which we are all so good at protecting.

If you write down your password and keep it in your wallet with your cash and do not write down your username or a hostname on it it is far less likely that someone can do something bad with it than if you don't write it down but choose a simplistic password. Hash cracking is the much larger threat than someone stealing your wallet and using your password.

And of course never use the same password twice or on different sites etc.

Answer 7

For me, it became so complicated to create and manage passwords, I researched and tested about 6-7 password managers and settled on a good one that was easy to use, backup, sync, etc. and am so glad I finally took the plunge.

ujrDm-e(5Gi9wSN8N.[(

Is a typical password that is generated, then all I need to do is copy/paste as required. One big strong passphrase is all I need to remember. This totally simplified and fortified my password usage.

Answer 8

I think a better answer than just password complexity rules is to have one (or two) simple password rules and teach your organization good password creation paradigms. Here is and example I use personally.

The rules: 1. Passwords must be 12 characters or more. 2. Passwords must contain alpha, number, and special characters.

Paradigm 1: 1. Pick a favorite saying or poem. 2. Take the a consistent letter in each word (1st, 2nd, last...) of the poem as a part of your password. 3. Apply your choice of alphabet substitution (could be hacket leet e->3, a->@...) but make up one if you don't have it. 4. If you need different passwords for different systems, prepend or postpend an acronym for the system name spelled backwards (bank -> knab) to the password.

For an organization you can come up with several paradigms if you want, or paradigms that have different levels of security criteria.

Of course the paradigms might need a little bit better explanation, but in general the benefit of this way is:

1. The "rules" are simple and can be quickly validated in UIs and other system components.
2. Your user community is tends to be more compliant to creating more robust and difficult to crack passwords, because they now have the mental tools to do so.
3. The recovery of passwords by the user is easier, and less risky (writing down of the actual password, vs. writing down the paradigm criteria).
4. Users can create system specific passwords that are fairly difficult, but still remember-able.