Good practice, Part 1: Password Policy

Good practice, Part 1: Password Policy

In the “Good practice” series, I will present my thoughts and opinions on different topics related to IT operations and security, and what I consider to be a good practice regarding them, based solely on my own experience and research. If I promote a product, I’m not payed to do so. The product is most likely just awesome.

You probably heard about the password policy “industry standard”; 8 characters minimum, complexity rules and expiration after 90 days. But is this good enough?


Why not?

Lets consider some aspects of this “industry standard”.

90 days expiration.

What happen if users are regularly enforced to change their password? First of all, they will be annoyed. Second, they will work against the best intentions of such a policy, by either making a sequential password (ex. Password1 -> Password2), or writing their password on a piece of paper within one meter from their desktop screen. They do this to make it easier for them self, and it’s not so hard to understand why. Never the less, security will be compromised.

And lets say that someone got hold of your users credentials one day after they changed their password. That would leave the attacker with 89 days of access. Knowing that an attacker might need less then a day to do potential harm, it would be safe to say that the 90 days rule won’t do much good, if used blindly without any other means of intrusion detection.

8 characters.

For many systems, 8 characters can be sufficient, but it isn’t if we are talking about a Windows environment. To keep it short, you have to make sure your users passwords are 15 characters at least. This is because of the Lanman hash, which will make every password of 14 or less characters exposed within minutes if someone are able to obtain the hash, not to mention the Pass the hash attack. The best part here is that even if you disable the use of Lanman in Group Policy, the hash will still be generated. If a password is longer then 14, the hash will be corrupt. 


Complexity isn’t bad in it self, but it can do harm rather then good if enforced without care. The password ‘Kds8_923#’ is actually much easier to break then ‘The summer this year was quite hot!’. The paradox here is that the password hardest for a human to remember, is the easiest for a computer to break, and vice versa.

My recommendation.

  • Min. 15 characters in length.
  • Min. 1 alpha and 1 non-alpha character.
  • No recurring password expiration.
  • Keep a password history of 10 or more password.
  • Deny sequential or small deviations to passwords when they change.
  • Enforce password changes only if you have reason to believe you have had a breach. People are much more likely to comply willingly in such a scenario, rather then to a 90 day cycle.
  • Promote phrases / sentences rather then weird and hard-to-remember combinations of characters to your users, so they more easily can create long and secure passwords.

As far as I can see, this policy and practice is the best compromise between security and user experience.

To implement this password policy, I would strongly recommend a product called Specops Password Policy. This product will extend your ability to make granulated and fine tuned rules for your password policy. I have had great experiences managing password policies this way, and AD by it self will not be able to fully support my recommendation.

Specops Password Policy example
Specops Password Policy