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.

  • possible duplicate of XKCD #936: Short complex password, or long dictionary passphrase? Commented Jul 23, 2014 at 20:50
  • Making password requirements so complex that they cause you to have to write down the password seems a tad counter-productive. It's only a matter of time before the good folks in IT ask for a Klingon character to be included in your password.
    – user121130
    Commented Aug 10, 2016 at 20:53
  • 2
    This is Dilbert's take on the subject: dilbert.com/strip/1998-04-06. Ironically, in 1998 it sounded like torture (and it is!), but 20 years later it is considered the norm. Hopefully in 10 more years the world will have moved on... Commented May 26, 2019 at 0:12

8 Answers 8


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.

  • 4
    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. Commented Jun 25, 2014 at 9:28
  • About 2: Once found myself choosing the first acceptable password per strcmp in ASCII.
    – fgrieu
    Commented Jun 7, 2017 at 18:06
  • 2
    most password complexity rules shrink the password space, making brute force easier. mixed case and at least one digit is such an example.
    – Skaperen
    Commented Aug 14, 2018 at 2:18
  • 1
    @Skaperen There are worse ones. I've dealt with 'password must be 8 characters'. Not 'at least 8', exactly 8. Also, things like 'no repeating adjacent characters' and 'you can't use the same character in the same position as a previous password'. That last one is really terrible, it basically forces you down a path of using keyboard sequences that you shift over time. The problem seems to be that enabling all available restrictions improves the password quality and the vendor has provided an extraordinary set of ridiculous options.
    – JimmyJames
    Commented Jan 17, 2020 at 19:59

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?

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.

  • This is a really great answer to the general question of how to approach "password strength": it has nothing to do with which character types you included, and everything to do with the total number of possible passwords based on the generation method you use. However, it doesn't speak very directly to the question of whether weird requirements can be counterproductive. Can you be more specific there?
    – NH.
    Commented Nov 21, 2017 at 18:25

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 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.

  • 1
    This answer is very helpful, especially with the link. I was wondering why nobody had voted it up before I saw it was posted only 5 hrs ago. So I just gave the first vote.
    – Cyker
    Commented Jul 12, 2018 at 2:32
  • Maybe this should also include a mention to the former NIST guideline, that said the exact opposite, just to reflect the change of standards over time.
    – Tom K.
    Commented Aug 14, 2018 at 5:45
  • Another key highlight is that, 'verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised'. This is gaining more traction since Troy Hunt added a feature to haveibeenpwned called 'Pwned Passwords API' where users and software may easily check (comparison via SHA-1) if the chosen password has already appeared in a breach (and thus reject it). A number of password managers leverage this, and some websites incorporate it too. It is a great step forward.
    – user53693
    Commented Aug 14, 2018 at 7:37

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.

  • 3
    "Easy compliance" may not be as true today as it was when this answer was written, thanks to sites blocking paste on password fields (morons).
    – Aaronaught
    Commented Feb 21, 2015 at 23:27
  • 1
    Also, there is no universal way to generate an acceptable passwords. Some sites require special characters, some other preclude them.
    – fgrieu
    Commented Jun 7, 2017 at 18:10
  • Hopefully the tigers don't like eggs. I'm guessing they do though. What carnivore doesn't?
    – JimmyJames
    Commented Jan 17, 2020 at 20:05

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.

  • 2
    So if you lose your wallet or have it stolen, then whoever gets the measly $50 you left in there will also now have access to your bank account with your life savings? Great idea... it's not like omitting the user name is going to help much either, because your wallet also contains your ID, banks cards, etc., so they can find out exactly who you are and where you have accounts (and probably call up their customer support and convince them that they "forgot my user name"...)
    – Aaronaught
    Commented Feb 21, 2015 at 23:22
  • 1
    @Aaronaught There's a trivial remedy. Add something you can easily remember to the written-down passwords. It may be the same thing for all passwords. So with your passwords being D.8frA+qH5YV, D.8fLJ27z_=+ and D.8f#y;QJP{4, I don't think that the thief will get much success without the first four characters. If the thief is an unrelated person, then the risk that they know your prefix or succeed cracking it is low.
    – maaartinus
    Commented Jun 9, 2017 at 13:08
  • Try cracking which example password? Have you tried John the Ripper on it?
    – NH.
    Commented Nov 21, 2017 at 18:27

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.

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.


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.


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.
  • 7
    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
    Commented Mar 14, 2014 at 16:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .