Something everyone can relate to is how a password policy on an application, whether for personal or business use, has impacted their login experience.
If you are anything like me, you remember a handful of old passwords you used when you were just starting out. We thought we were so clever back then. Using curse words or names of our crush at first but then graduating to using a one instead of an “I” or an “L” — brilliant.
Let me tell you a story about one of my first passwords; how I forgot it, how I remembered it, and how I will never forget it again.
Memorable times with a password policy
I had an old G4 Macintosh I used solely to play music. This was in the days of Napster so I “borrowed” a lot of music back then. Every day, I’d boot up my Mac alongside my Windows computer. Fast forward several years, I bought my first house and blew the dust off my old G4. I hooked up some killer speakers and this was going to be my man cave media player. My elation quickly faded after startup when I realized I couldn’t login. I can’t tell you how many different password combinations I tried, but all I know for sure is, I’ll always remember the motion of the password bar shaking after an unsuccessful attempt.
After about an hour, I moved into the acceptance stage of my grief but every few days I’d try again until finally I remembered. When I first setup the Mac, I wanted to log in quickly. That clear G4 keyboard had a nice full number pad with an enter key on the bottom right. I felt like I was hit by a strike of lightning and rushed downstairs, started the computer and typed zero, then “Enter.” My password was the number zero. It was so brilliant, so simple, and so stupid.
Password composition has changed dramatically over the last 10-15 years. Speaking strictly about Microsoft Active Directory password policy, the reason for these drastic changes is due to the introduction of Fine Grained Password Policies (FGPP) and industries shifting from on-prem into the cloud. These two events specifically have had a very large impact on password recommendations and are the exact reasons why one password policy does not fit all. That is why this article literally begins at zero.
Old school approaches
When Active Directory launched in 2000, Microsoft implemented one policy to rule them all. Meaning, only one password policy could be implemented for any domain. When implementing this one-size-fits-all policy, the Administrator is really tasked with identifying the smallest common denominator. Often, this results in a weak password policy that must accommodate for old systems that don’t support a password over eight characters, or worse.
The Active Directory password policy settings are located by opening the Group Policy Management Console (GPMC) and editing the Default Domain Policy or another policy linked to the root of the domain. To get there, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy.
By default, the settings have looked like this for about 15 years.
Password policy settings
Each of the six password policy settings provides its own unique security measure.
Enforce password history
This setting determines how many previous passwords are remembered for a user account. The intention of this setting is to protect against password reuse. Critics typically cite this setting as heavily lacking because it still allows users to reuse passwords by simply incrementing the last character (Example: Fall2022 to Fall2023). Despite this criticism, Microsoft continues to recommend 24 passwords remembered.
Maximum password age
This setting determines how long a password is valid before requiring a change. This setting is often referenced as password expiration and has been the topic of controversy for several years now. NIST famously released Special Publication 800-63B in 2017, which suggests passwords should never expire. Microsoft also dropped their password age recommendation (previously 60 days) when they released the security baseline for Windows Server v1903. Concerning this decision, Microsoft explains, “Removing a low value setting from our baseline and not compensating with something else in the baseline does not mean we are lowering security standards. It simply reinforces that security cannot be achieved entirely with baselines.” They also note in their best practices, “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.” The article is still recommending a password age between 30 and 90 days.
Minimum password age
This setting determines the amount of time a password must remain valid before it can be changed again. The recommendation for this setting is one day. It protects against a non-complaint user immediately changing a password 24 times before returning to the original password.
Minimum password length
This setting determines the number of characters a password must be in order to be valid. Password length is another controversial setting. Shorter passwords can be more easily guessed or cracked but enforcing long passwords may encourage end users to write them down or reuse them on other applications. Microsoft currently recommends 14-character passwords in their security baseline but also maintains that eight characters may be sufficient for most environments.
Password must meet complexity requirements
This setting determines whether passwords must abide by complexity requirements. Microsoft recommends this setting be enabled. When this setting is enabled, it prevents a password that includes the account username or full name. It also forces a password to contain three of five categories (uppercase, lowercase, numeric, special character, or Unicode).
Store passwords using reversible encryption
This setting allows for passwords to be stored in a way that allows for password decryption. Accounts that utilize reversible encryption have password attributes that can be easily decrypted to their clear-text equivalent. Microsoft recommends keeping this setting disabled.
Microsoft provides a thorough explanation including best practices for all of these settings here. Unfortunately, some of these settings are limited in their possible values. A minimum password length greater than 14 characters is not currently supported using this password policy without Domain Controllers running Windows Server 2004. That’s where fine-grained password policies (FGPP) come in.
Fine-grained password policy (FGPP)
Introduced in Windows Server 2008, FGPP gave administrators the freedom to place more strict password guidelines on a subset of users. Recommendations for FGPP are typically to apply a specific policy to accounts with elevated privileges or to enforce a different policy on Microsoft service accounts. Although FGPPs expanded the ranges for settings such as the minimum password length, they are still restricted to the same attributes as the original password policy. These limitations leave domain users vulnerable to password attacks such as password spraying and credential stuffing. It also does not contain the flexibility required to abide by recent compliance guidelines such as NIST or even Microsoft’s best practices.
Microsoft recognizes that their “small set of ancient password policies enforceable through Windows’ security templates” are no longer sufficient. Instead, they recommend further strengthening password security by implementing a banned password list, eliminating password reuse, and enforcing multi-factor authentication (MFA).
Azure Active Directory password policy
Microsoft has used their cloud platform to expand upon the previously suppressive password policies. By leveraging integrations with on-premises Active Directory(AD) and implementing new technologies, Microsoft has provided a toolkit that further advances password security. Some examples include Azure AD Password Protection, Password Hash Synchronization (PHS), monitoring, and MFA.
Password protection implements a password filter for AD and Azure AD. This filter prevents accounts from using passwords on a banned password list. Password filters typically block the use of weak passwords, compromised passwords, or passwords that include words common to the business.
Reduce your AD attack surface.
Password hash synchronization (PHS) is an option when working in a hybrid identity model as it syncs the password hash from on-premises to Azure AD. The key feature that PHS provides is leaked credential detection. This is a form of password auditing that checks passwords against known breached credentials. Password auditing occurs continuously instead of only at the time of password change. This form of monitoring not only protects users with leaked credentials but also helps to combat password reuse.
Similarly, Azure AD Identity Protection is able to identify potentially suspicious behavior and take action. It does this by evaluating risk associated with sign-in activities and the user in general. Risky sign-in behaviors might be login attempts from an atypical location or a possible password spray attack. An example of risky user behavior would be the detection of activities that may be unusual for the specific user account. Identity Protection monitors for these risky events and will alarm or take action automatically.
MFA is not specifically a password protection, but it is possibly the best method to protect accounts from attack and is an important tool provided by Microsoft for Azure AD. Most recommendations these days include MFA. Azure AD offers security defaults and conditional access policies as flexible methods of deploying MFA in a tenant.
Conclusion
Password policies are (and always have been) a balancing act. A password policy is a collision between security and user impact. There are very few companies out there with the ability to follow NIST guidelines. That’s why it’s so important to consider the options available to any given environment. For instance, an environment that enforces MFA may be able to relax its password length requirements. On the other hand, an environment without MFA may consider a stricter password age or implementation of password auditing. There’s no one right answer to the password policy question. Well, maybe do not allow a password of zero. But on the other hand, it may not be as easy to guess as you might think.
