Password policy is a very difficult subject. Every organization has a different approach and technical means to secure the data in their systems. However, very often I come across something that realistically does more harm than good - password expiration policies!
The problem of password expiration policies
As the name suggests, an expiration password policy is used to enforce a system-wide change of a user’s password after a specified number of days since it was last changed. Tempting, isn’t it? Well, if your password is compromised somewhere, you’ll change it in 30 days and the attacker won’t be able to use it. Sound safe? Sure, but why would this setting actually decrease our security instead of increasing it?
Because people are lazy by nature 🙂 Instead of creating unique passwords each time, users will very quickly create new ones according to their own schemes and habits. What do these habits look like? Changing the end of the current password, adding a letter or number, etc. Is such a password secure? Uh, not really… If we can guess the next iteration of the password, that doesn’t guarantee us any security at all.
Let’s put ourselves in the user’s shoes for a moment. If a company has a bunch of non-integrated systems that require the use of a ton of different logins and passwords, then this situation actually encourages the user to mess around. Unfortunately, very often the employee has no idea that this can have tragic consequences.
Security standards versus password expiration
Seems reasonable, but we had a security audit ten years ago that recommended password expiration, so something’s wrong here… Actually, 10 years ago we might have heard such a suggestion. However, things change and policies and procedures should be constantly updated. Can we find this recommendation now? Let’s check!
Microsoft security baseline
Regarding Active Directory domain:
The security baseline recommended by Microsoft doesn’t contain the password-expiration policy, as it is less effective than modern mitigations. However, companies that didn’t implement Azure AD Password Protection, multifactor authentication, or other modern mitigations of password-guessing attacks, should leave this policy in effect.
In case you’re curious: I wrote a separate post explaining what the Azure AD Microsoft Entra Password Protection service is and how it works in practice.
Regarding Microsoft 365:
Password expiration requirements do more harm than good, because these requirements make users select predictable passwords, composed of sequential words and numbers that are closely related to each other. In these cases, the next password can be predicted based on the previous password. Password expiration requirements offer no containment benefits because cybercriminals almost always use credentials as soon as they compromise them.
National Institute of Standards and Technology (NIST)
In the publication Digital Identity Guidelines Authentication and Lifecycle Management:
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
— NIST Special Publication 800-63B - 5.1.1.2 Memorized Secret Verifiers
Center for Internet Security (CIS)
In the publication CIS Password Policy Guide:
Excessive password expiration requirements do more harm than good,because these requirements make users select predictable passwords, composed of sequential words and numbers that are closely related to each other. In these cases, the next password can be predicted based on the previous one (incrementing a number used in the password for example). Also, password expiration requirements offer no containment benefits because attackers will often use credentials as soon as they compromise them.
However, to make sure I don’t just cut out the parts that are convenient for me, there is also this note in the CIS Password Policy Guide:
In addition, we also recommend a yearly password change. This is primarily because for all their good intentions users will share credentials across accounts. Therefore, even if a breach is publicly identified, the user may not see this notification, or forget they have an account on that site. This could leave a shared credential vulnerable indefinitely. Having an organizational policy of a 1-year (annual) password expiration is a reasonable compromise to mitigate this with minimal user burden.
Are you saying that password expiration should be turned off?
Well that depends 🙂
If your organization has other tools in place to protect against password guessing attacks, then after a risk analysis you may want to make life easier for your users. On the other hand, if you’re just starting to “harden” passwords, integrate identities and generally upgrade your infrastructure, then maybe consider changing this setting to 90 days or more?
In general try to avoid low values for this setting such as changing passwords every 30 days.
How to disable password expiration?
The setting location depends on the service/system you are using. This post covers the configuration for the Active Directory service.
Default Domain Policy
When you create a new Active Directory domain, a default GPO policy named Default Domain Policy is created. This is where we’ll find our password policy settings.
The path is a bit tricky, because of course we would look for the setting in the User Configuration, and here’s a surprise, because the setting is in the Computer Configuration path.
Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy
All that remains is to enter a new value or disable the Maximum password age policy.
Fine-Grained Password Policy
Creating a new GPO policy for users in a particular OU sounds like a good way to change the Maximum password age setting. Well, it seems to be. Of course, we can create such a policy because the system won’t prevent us from doing so, but will it work? The answer is that it won’t. We should use the Fine Grained Password Policy feature instead.
The configuration
Open the Active Directory Administrative Center and select your domain:
Go to System > Password Settings Container and select New > Password Settings
Create a new custom password policy and select the target users or security group.
Done. Once created, it should appear in our list.
How to verify that the policy is working?
Active Directory Administrative Center
Browse to the test user and select “View resultant password settings…”. If the user has a policy assigned, we’ll see the policy properties.
You will receive a message that no such setting exists if the user doesn’t have a fine-grained password policy.
PowerShell
You can use PowerShell to check settings if you don’t want to use the Active Directory Administrative Center.
| |
The result of the command before change:
The result of the command after change:
As you can see our policy worked.
What about Microsoft 365 / Azure AD Entra ID?
Well, nothing… If you have AD Connect, then by default password expiration is disabled in Azure AD Entra ID for all synchronized accounts. Our changes to the default domain policy or the creation of a fine-grained password policy have no effect. This means that by default, if your password expires on-premises, you will still be able to sign in to Microsoft 365.
Unless you’ve configured a Conditional Access Policy, which can force you to work from a company-owned computer that interacts with the domain and will ask you to change your password 🙂
Conclusion
You’ve just learned that using password expiration policies doesn’t make your organization more secure, and usually does the opposite of what we thought. If you’re curious about this topic, I strongly encourage you to follow the Password Policy tag for more technology and tools on similar topics.