Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
2  
Look up 'BatteryHorseStaple', XKCD. xkcd.com/936 if you're lazy :-P –  grauwulf Mar 7 '13 at 23:12
2  
For a while my password for MVP (my health insurance company) was literally FuckY0uMVP!123 because of their absurd complexity requirements. If I, as a security conscious individual am so frustrated as to deliberately fight them, I can only imagine what an average user would think. –  AJ Henderson Mar 8 '13 at 0:11
    
@grauwulf - the term is "Correct Horse Battery Staple" :) –  KeithS Jul 23 at 19:19
    

6 Answers 6

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 bloody password rules 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.

share|improve this answer
    
And if the requirements are made public then it gives attackers added information. They'll know that each password has, for instance, "at least four special characters and three numbers." Also, #2 was spot on. –  eric_lagergren Jun 25 at 9:28

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.

share|improve this answer

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 2n possible passwords, and the attacker will on average need to try half of that, 2n-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)5 = 1010 ≈ 233. 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.

share|improve this answer
    
The XKCD reference is great - TLDR the XKCD at the top of your post and i'll upvote it :) –  OakNinja Mar 7 '13 at 23:19

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.

share|improve this answer

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.
share|improve this answer

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.
share|improve this answer
3  
If I had the rep here, this would be a -1. The paradigm you suggest compromises the password security. Security comes from the generation process. See this answer Any process that starts with "favorite" fails the "uses mammalian cognition to generate randomness" test. Any attacker who knows the process can then apply it to a collection of common quotes/1-8 word phrases and crack your password. Also read this article. –  Eponymous Mar 14 at 16:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.