]> Should I enforce password complexity? 🌐:aligrant.com

Should I enforce password complexity?

Alastair Grant | Mon 29 Jan 2018


Let me explain why not.  Password complexity is one method for making passwords harder to guess and protecting against brute force attacks.  I'll start by addressing the simple psychological one, most people who are forced to add numbers to their passwords will go with character sub5t1uti0n, or just tag a number on the end1 (especially if a password history is enforced).  The number of extra guesses to take an easily guessable password and swapping out some characters is trivial.

Neither is it affective against brute-force attacks.  The important thing to look at is what the system allows and not what is used.  If somebody only uses upper case characters, that's restricting the number of possible characters that could be used, but if system supports upper case characters too, then an attacker can't assume that a password is going to be just in upper case and has to try a mix.

With this in mind, lets look at a working example on a system that will allow any case letter (26 x 2 = 52), numbers (10) and symbols (34) from the printable ASCII set, giving us 96 possible characters.

We'll start with a lowly four character password.  Each character has 96 possible characters, so there are 96 x 96 x 96 x 96 possible combinations, or about 85 million.

Now lets implement a fairly common password policy:

  • Must have at least 1 upper case character
  • Must have at least 1 number
  • Must have at least 1 symbol

The idea behind this, is that the system is forcing the user to make use of the full 96 characters available to them.  This is a good intention, but as soon as you enforce it, you actually reduce the number of possible combinations:

1 upper case character means a user cannot use lower case, numbers or symbols in one of your positions.  The sum is now 26 x 96 x 96 x 96, or 23 million.  That's a massive reduction in combinations.

Add 1 number: 26 x 10 x 96 x 96 = 2.4 million

Add 1 symbol: 26 x 10 x 34 x 96 = 850 thousand.

By enforcing this password policy we've taken an attack of 85 million possible combinations down to under 1 million guesses required.  This is why you should not enforce a policy.  You can still recommend people use this combinations, but as soon as you enforce it, an attacker can remove anything that doesn't match.

How about length?

Size matters in security.

Lets work our example up to a 5 character password: 96 x 96 x 96 x 96 x 96 = 8 billion combinations!  Each time you add a character onto the end of the password you force an attacker to go through all the possible combinations you already had, plus them all again another 96 times.

Should you enforce a minimum length?  Absolutely, as the above point stands.  Whilst the attacker knows they don't have to try short passwords, they're easier to generate than long passwords.  The protection comes from the length.


The problem with long passwords is that they're tricky to remember.  Instead recommend users combine several random words together (you need several words to protect against dictionary attacks).  A sentence for instance.  These are often easier to remember and make brute force attacks unfeasible.


Password policies can actually reduce the complexity of your passwords.  If you do use them, they have to be in addition to the an already long minimum password length.  e.g. if you specify a 12 character password, you could then say 1 upper, 1 number and 1 special on top of that, and make the minimum length 15 characters.  But at this length of password with a potential to already use those characters, you're only doing it to satisfy an uninformed password policy.

Educating your users about what constitutes a strong password, and how to securely store them is far more useful in providing real security.  Along with other security approaches where necessary (e.g. selective MFA, network location restrictions etc).

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.