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.

Begs 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 them can enforce;
2. incite user to choose creative workarounds to go past the bloody password that this pathetic worm of a sysadmin uses to express his spite at the world and his revenge on Diana from accounting who won't date him because he is an ugly and smelly geek and I hope he gets maimed by an enraged raccoon and stray dogs will come to urinate on his grave. Dammit.
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

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 3

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 4

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? (warning: skip Jeff Atwood's answer, even though it is currently the top-scoring one, because he blithely ignores the math).

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 5

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.