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:
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.
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.
I couldn’t agree more. Given the usual amount of time i spent on resetting forgotten passwords, because the user had to change is password right before his vacation and then forgot all about it, i can only guess how many times our primary Help-Desk has do this and how many time and good money is wasted because of the many flaws in password policies which you pointed out so nicely.
I would like to add one thing. While the argumentation works great with user accounts, many companies also use functional accounts like “CTX_Admin” for various automated tasks and scripts. These accounts, despite the fact that they usually have administrator privileges, usually don’t have strong passwords or a maximum age. The main problem here is that many people, too many people, know these passwords. They may leave the company but the password stays the same. Or in case of an emergency, the password may be given to am expert from another company. In short, these functional accounts are, in my opinion, a huge security hole in every large directory, if they are not properly administrated. Or in other words, the password to an account should always be known by only one person.
Thanks for your comments, Michael. Service account passwords are indeed a problem of their own.
So I’m not the only one… For many years I have known that the blockhead “password change policy” reduces security, but I’ve never expressed it this clearly.
There is a conflict of interest: The user protects his information and resources to the degree necessary, but the operator also protects the domain and the information and resources that the use doesn’t own, but may access.
The password change policies of the World realy, really have to go bye-bye.
In a bank that I worked for, we had of course draconian protections in place, but a brilliant password recovery policy: Any two colleagues in your work group could reset your password at any time.
Notice that the goal is NOT to prevent actions by employees, but to prevent outsiders and to hold employees accountable. If any two employees want to forfeit their employment for the sake of a password prank, be my guest…
Not to forget: One idea behind this is changing passwords more frequently than it might take to brute force them. Yes, it’s kind of a pain, but disabling passwords and favor Smartcards unfortunately does not work today as far too many applications rely on passwords and won’t work with pure Kerberos and UPNs…
Change ASAP a Well-Remembered Password on all your 1000 accounts if ist shown up on haveibeenpwned