How Forcing Password Changes Actually Weakens Security

When was the last time you got that not too friendly message stating that your password has expired and asking you to change it? Probably only a few weeks ago, and just as sure as day follows night, it is going to appear again only too soon. At least that is the typical user's point of view. Security conscious administrators see this differently: they seem to think that passwords become weaker over time, like human beings growing old, and therefore force a rejuvenation process every couple of weeks. But is that really necessary? I do not think so.

Ingredients of a Good Password

Good passwords are not so easy to come by. They must be difficult to compute for machines and hard to guess for humans. That means they must:

• have a certain minimum length,
• contain elements from different sections of a large pool of characters,
• not be (solely) composed of words found in dictionaries, and
• not be trivial, i.e. the name of someone's dog.

In order to get their users to choose strong passwords, administrators can configure a domain password policy according to their needs. The following screen shot shows the options available on Windows Server 2008:

Dissecting Password Policy Options

Let us skip the first three options and start with number four, Minimum password length. Obviously, this corresponds to the first of our earlier requirements. Choose this number as high as you dare.

Now, on to Password must meet complexity requirements. Sounds good, but what does it actually mean? Here is the explanation from the policy:

"If this policy is enabled, passwords must meet the following minimum requirements:

• Not contain the user's account name or parts of the user's full name that exceed two consecutive characters
• Be at least six characters in length
• Contain characters from three of the following four categories:
• English uppercase characters (A through Z)
• English lowercase characters (a through z)
• Base 10 digits (0 through 9)
• Non-alphabetic characters (for example, !, $, #, %)"

Enabling this complexity policy meets our second requirement from above and, partially, the fourth. Obviously, the system cannot know the names of our spouses, children, cats, dogs, favorite actors, etc. So it does what it can, which is to check the password against parts of the user name.

That leaves us with our third requirement. Does Windows offer a protection against dictionary attacks? Unfortunately not. The policy options that are available have not changed at least since Windows Server 2003 and leave much room for improvement. Look at the following strings, which Windows would consider as complex:

• !23456A
• Abcdef0=
• Qwerty7/
• Mary4Me!
• Secure2!

Considering this, using one of the third-party password strength enforcement products or two-factor authentication solutions is a must.

Never Change a Well-Remembered Password

But wait. There are three additional password policy options I have not yet covered. Those three (password history, minimum and maximum age) are all about forcing users to change their passwords regularly. How does that help? It does not.

Yes, users tend to choose simple, weak passwords. But they do that each time! In fact, passwords are getting weaker if they have to be changed frequently. Users are not stupid. They understand full well that they have to go through the change process again and again, and they will adapt by making the process as easy and painless for them as possible. The most common tactic is to use a "base password" and append a number that is incremented at each cycle, going from "Password01=" to "Password02=" and so on. The only problem (from a user's perspective) is remembering which number is currently required. The "obvious" solution is to write that information down, in "encrypted" form somewhere near the keyboard.

Now, how secure is that?

If you want to prevent that from happening, do not force your users to change their passwords, at least not every few weeks! Do not waste your company's money - a percentage of those password changes goes wrong each time, and the unlocking process is frustrating and time-consuming. The same can of course be said of the password change process as a whole.

Addendum

Do you wonder why I did not mention the last policy option Store passwords using reversible encryption? Because it effectively disables password encryption. The policy help text is quite explicit on this:

"Storing passwords using reversible encryption is essentially the same as storing plaintext versions of the passwords. For this reason, this policy should never be enabled unless application requirements outweigh the need to protect password information."

Sounds clear enough to me.