Is the default Active Directory password policy good?

One of the first things I do after I set up a new domain is change the default Active Directory password policy. If you didn’t do this, you have a security problem. In addition, you are wasting your organization’s money.

Group Policy settings

The password policy is configured via Group Policy and can be found at Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy:

Seriously, I can’t take such “best practices” articles seriously. The rest of the article is in the same style. All you know after reading the article is that it is really totally up to you. The truth is that there is no such thing as “best practices” when it comes to password policies. It is like trying to write a general dress code that works for Alaska, Africa, and Amalthea.

Factors influencing the password policy

And this is not only about the level of security a company requires. Another important factor is the technical environment in which your network lives. For instance, it makes a huge difference whether users can log on via the Internet (hopefully VPN) and whether your domain controllers are safe behind a well-configured firewall. Of course, many other factors exist such as network size, physical security, or Windows versions.

Perhaps even more important than technical factors are social factors. The more technical security has improved in our networks, the more important social engineering has become for hackers. Thus, you have to answer the question of what kind of users you have. Are they more like the naïve fellow who would give the password to anyone who claims to be an admin in an email, or have your users been trained against social engineering attacks?

Now, you could say that if it is unclear what password policy is best for your environment, you simply set the strictest policy to be on the safe side. This is most certainly the worst thing you can do. You would only be on the safe side with wasting your company’s money. Tight password policies significantly increase costs because you will need more support personnel to help users with forgotten passwords. Perhaps the lost productivity when users can’t work because they can’t log on (trying to remember all morning the new password they were forced to set yesterday) is even more significant.

So what can you do if no best practices exist for password policies? All I can do is give you a few tips. Much of what I say now is based on views and experience. From the password policy settings you see in the screenshot above, only four really matter: maximum password age, maximum password length, password complexity, and reversible encryption.

Reverse encryption

The last one is easy. Don’t change the default setting of “disabled.” You only have to decrypt Active Directory passwords if you have to sync them with a database. You must have good reasons if you change the default setting because allowing reverse encryption significantly reduces security.

Password complexity

I also wouldn’t change the default password complexity setting. It is true that requiring password complexity makes it more likely that a user will forget the password, but with a little user training you can easily solve the problem. I recommend giving users a procedure that helps them choose a good password that is easy to remember.

One option is to choose a sentence that they can memorize easily and then choose the first letter of each word for the password. Perhaps half of the password could be in capital letters and the other half in lowercase ones. Mix in a non-alphabetic character at the beginning, middle, or end and you have a fine password.

Many security experts recommend setting a random password (such as in the paper mentioned above). This advice typically comes from security experts who are too focused on technology.

I am totally against this practice. This will not only increase costs but also reduce security. Nobody can remember those random passwords. The result is that users will pin the passwords on their monitors. You can tell them a thousand times that they mustn’t do this, but they will do it anyway.

This is not the only security problem. Users will get the passwords from their neighbors to read their emails or, even worse, write emails from the accounts of others. Trust me, they will!

Maximum password length

The default maximum password length is an outdated setting. A password consisting of seven characters is no longer adequate. Many security experts say 10 characters is currently the state of the art, and I agree. This number is not based on folklore but on actual penetration tests. If you give your users tips for thinking of a good password they can easily remember, a password length of 10 is not really a problem.

However, as mentioned above this can’t be a general recommendation. Environments exist where no password is fine (test environments without internet access, for instance) and in some situations you need a password where 10 characters appear to be ridcuously small (servers with direct high-speed internet access that store confidential data, for instance). Nobody can remove the responsibilty from you to analyze your own situation. The 10 characters are just the minimum you need in the average brick-and-mortar business.

Maximum password age

With long passwords, you can also be more generous with the maximum password age. This setting is the most crucial one when it comes to annoying users and increasing costs. The default setting of 42 days does not make sense at all to me. As with random passwords, users will start pinning passwords because, at some point, they will get tired of calling the help desk every 42 days.

The maximum password age is supposed to help against brute force attacks. However, it is the worst method for this purpose. Let me cite another paragraph from the Singer-Anderson paper:

The FIPS guidelines actually acknowledge that the load on users created by frequent password changes creates its own risks, which in many contexts outweigh those created by changing a password less frequently.

Much better measures exist against brute force attacks. One is longer passwords.

Also important is the account lockout threshold policy. It is disabled by default, which is not good. I have had good experiences with a maximum of five invalid login attempts.

                      
This policy protects much better against brute force attacks than does the maximum password age and has the advantage that users don’t blame you if they mistyped the password too often because they know they made a mistake. However, if you set a strict maximum password age, you are the one who prevents them from getting their work done.

In addition, you should have an intrusion detection/prevention solution that detects brute force attacks and illegitimate account usages. These are much more appropriate measures than imposing a maximum password age is.

Security experts may stone me to death for saying this, but disabling the maximum password age altogether is quite fine with me if you follow the other tips above. The security benefits of this policy are not related to its costs. It is better to throw in a manual password reset round if your intrusion detection system discovered unusual activities. And if you are afraid that you will be blamed in case of a security incident, you can set a high maximum password age such as 180 days.

Another thing that is wrong with the default Active Directory password policy is that it applies its setting to the entire domain. Of course, you must differentiate between admins and perhaps also between users depending on rank. I would even set a maximum password age for admins. They are used to handling passwords and often can reset their passwords from a second account. Of course, it would also be helpful if you have a self-service password reset tool for end users. This would allow you to set a stricter password policy.