What are the best practices for your password policy? As an administrator, you are responsible for establishing the password policy for your organization’s users. Setting a password policy may be difficult and complex, and this article covers the pros and cons of Microsoft’s past recommendations versus their new password policy recommendations. At the same time, we offer you suggestions to help your company become safer against password vulnerabilities.
Understanding the Password Policy
If you look online for recommendations for your password policy, you will find a plethora of information that all seems to contradict each other. For example, Microsoft used to suggest the following:
- Minimum password length of 8 characters or more
- Have complexity enabled
- Maximum password age set to 60-90 days
- Enforce password history of 24
- Minimum password age set to 1 or higher
- Do not store passwords in reversible encryption unless needed
If you look at recommendations from other organizations, many will have something similar opinions to the above but usually with a longer minimum password age of 12 characters.
Before we get too deep into recommendations and current best practices, let’s cover each of the settings in Microsoft’s password policy and why they are essential from a security standpoint. We’ll also include our thoughts from a penetration testing standpoint.
Minimum password length – The minimum number of characters that can be used as a password for a user account is determined by the Minimum password length policy option. Having a minimum password length of more characters makes the password more difficult to guess and can typically make it more challenging to crack the hash (encrypted password) if an attacker obtains a password hash.
Password must meet complexity requirements – The passwords must adhere to complexity standards. The policy setting controls whether passwords must meet a set of strong-password requirements. When enabled, this feature necessitates the following specifications for passwords:
- Passwords cannot contain the user’s samAccountName (Account Name) value or entire displayName (Full Name value). Both checks aren’t case-sensitive.
- The password includes characters from three of the following categories:
- Uppercase letters
- Lowercase letters
- Base 10 digits (0 through 9)
- Special characters such as: (~!@#$%^&*_-+=`|\(){}[]:;”‘<>,.?/)
- Any Unicode character categorized as an alphabetic character isn’t uppercase or lowercase. This group includes Unicode characters from Asian languages.
Complexity makes it more difficult to guess passwords and increases the time to crack a password hash if one is obtained.
Maximum password age – The amount of time (in days) that a password may be used before the system asks the user to update it. You can indicate that passwords never expire by setting the number of days to 0, or you can configure passwords to expire after several days (between 1 and 999).
Suppose a password hash was captured, and it took months to crack it, or the password was leaked online. In that case, having a maximum password age set to 60 days may prevent an attacker from accessing resources if the current password is different. From a penetration tester’s perspective, we’ve seen many organizations set their maximum password age to 90 days but found that many users use predictable passwords when this happens. For example, as of this writing, it is June 2022. Therefore, users might use a password like Summer22 or Summer2022, then increment the season in 90 days to Fall2022, etc. If a password changes too often, it may lead to more helpdesk tickets for forgotten passwords or employees writing passwords on sticky notes on their monitors.
Enforce password history – The number of unique new passwords that must be connected with a user account before an old password may be reused is determined by the Enforce password history policy option. In every organization, password reuse is a significant risk. Many users choose to keep the same password for their account for an extended length of time. The longer the same password is used for a specific account, the more likely an attacker will be able to identify the password using brute force attacks. If users are compelled to change their password but may reuse an old one, the impact of a strong password policy is considerably diminished. Users can continue to use the same limited number of passwords by specifying a low value for Enforce password history.
Minimum password age – The Minimum password age policy option specifies the amount of time (in days) that a password must be used before the user can change it. You can select a value between 1 and 998 days or enable password changes instantly by setting the number of days to 0. Unless the maximum password age is set to 0, which indicates that passwords will never expire, the minimum password age must be smaller than the maximum password age.
From a security standpoint, having a minimum password age of 0 enables users to cycle through passwords to reach their original password. Microsoft recommends setting this to at least 1 (1 day).
Store passwords using reversible encryption – The Store password using reversible encryption policy setting support apps that employ protocols that need the user’s password for authentication. Storing encrypted passwords in a reversible manner means that the encrypted passwords can be decrypted. A skilled attacker who can crack this encryption can access network resources using the compromised account. As a result, unless application needs outweigh the need to secure password information, never store passwords using reversible encryption.
From a penetration tester’s point of view, any organization storing passwords using reversible encryption is the same as storing passwords on the domain controller in cleartext. If an attacker obtains the NTDS.dit file containing all NTLM hashes (hashes for all Active Directory accounts), the attacker can instantly view all passwords without cracking any password hashes.
Microsoft’s Current Best Practices for Your Password Policy
At first glance, Microsoft’s current best practices for password policy adherence seem counterintuitive. It makes sense to have longer passwords with a longer minimum length requirement as attackers have the more advanced computing power to crack encrypted passwords (password hashes), but now Microsoft says the opposite. Microsoft also does not recommend requiring complexity requirements and not mandating periodic password resets (no maximum password age). While you may be confused with these changes, let us explain why they state their case. Note that the below statements are from Microsoft and not our direct opinion.
User password expiration requirements
Microsoft states that password expiry restrictions create more of a drawback than a benefit because they force users to choose predictable passwords made up of consecutive words and digits that are closely connected. In some circumstances, depending on the previous password, the future password may be anticipated. Password expiry rules provide little containment advantages since attackers mainly exploit compromised credentials immediately. Microsoft provides an article with more information about this specific requirement found here.
Requiring long passwords
Password length requirements (more than ten characters) might lead to predictable and unfavorable user behavior. Users who are forced to use a 16-character password, for example, may pick repeating patterns such as “fourfourfourfour” or “passwordpassword” that match the character length requirement but are not difficult to guess. Furthermore, length constraints increase the likelihood that users may utilize risky methods such as writing down passwords, reusing them, or keeping them unencrypted in documents. We advocate retaining a modest 8-character minimum length limit to encourage people to think about creating a unique password.
Requiring the use of multiple character sets
Password complexity requirements reduce key space and force users to behave predictably, causing more damage than good. Most systems require some amount of password difficulty. Passwords, for example, need characters from all three of the following categories:
- Lowercase characters
- Uppercase characters
- Non-alphanumeric characters
Most individuals follow a similar pattern: a capital letter in the first position, a symbol in the last, and a number in the final two. Because cybercriminals are aware of this, they conduct dictionary attacks utilizing the most popular replacements, such as “$” for “s,” “@” for “a,” and “1” for “l.” Forcing users to select an upper, lower, digit, or special character has an adverse effect. Some complexity requirements even hinder users from using safe and memorable passwords, forcing them to choose less secure and memorable passwords.
Our Opinion on Microsoft’s Best Practices for Your Password Policy
After performing thousands of penetration tests for small, medium, and large enterprise companies, our opinion is slightly different than Microsoft’s recommendations.
Password expiration requirements
For password expiration requirements, we understand that some users will use incremental passwords when changing their passwords. The issue is that some users will inevitably use their passwords on other sites with the same password they use for work. If the other site using the same password is compromised, there is a chance that their password will be a by the time the attacker uses it. While this may not always be the case, it is better to have a smaller chance of this outcome than not.
If the password does not expire, the user should use a longer password phrase such as “Logic Finite Eager,” which takes exponentially longer to crack.
Requiring long passwords
Microsoft states that using long passwords such as 16-characters will increase the likelihood of users writing down passwords or storing them in unencrypted documents. This likelihood can be true if the user creates traditional passwords such as “OwmfPbeHQkemK4LW”. If they generate password phrases, the chances of this happening are drastically reduced. The previous example of “Logic Finite Eager” is 18 characters, but it is much easy to remember. Having a minimum password length of 8 characters with no complexity will have users creating very weak passwords such as “password” or your company’s name. Even if the organization blocks common weak passwords or common words, users will inevitably create passwords using weaker strategies or keyboard walks such as “1qaz2wsx” or “cde#xsw@”. Additionally, using modern graphic cards, 8-character password hashes (NTLM hashes) can have their password cracked for all possible combinations in less than 30 minutes.
Password complexity requirements
We agree with Microsoft’s logic on password complexity requirements. After cracking thousands of user password hashes we also found the trend of user-created passwords that start with a capital letter and end with numbers or a special character (e.g., “Password1” or “Password!”). We also think that if a user does use a password phrase, then having password complexity would not be necessary. Using the previous example of “Logic Finite Eager,” this password would still be secure if it were “logic finite eager.”
What do you recommend as best practices for your password policy?
The primary goal of a more secure password system is password variation. You want your password policy to include a variety of passwords that are difficult to guess. Here are some suggestions for making your company as secure as possible.
- Educate users on creating password phrases instead of using traditional or single-word passwords or have users create a password phrase utilizing a password generator.
- Require a 14-character minimum password length. If you use this minimum length, then the following do not need to be mandatory:
- Password complexity
- Mandatory periodic password resets (maximum password age can be set to zero)
- Avoid using common passwords to keep the weakest passwords out of your system. This can be achieved by creating fine-grained password policies, using Active Directory with Azure, or using third-party tooling such as “Have I Been Pwned” (HIBP) API.
- Educate users not to reuse their company passwords on other non-work systems.
- Ensure all administrators use different passwords from each other and for each service account. All administrator passwords should use long password phrases.
- Require multi-factor authentication for external services that require authentication. For any high-risk internal system, it is also advised to use multi-factor authentication.
- Require risk-based multi-factor authentication challenges.
How can you determine if your employees are using strong passwords?
An excellent way to determine if employees are using strong passwords is by performing an internal penetration test. This testing discovers hidden vulnerabilities within your network and allows you to see if your best practices for your password policy are up to par or need improvement. An internal penetration test will let you know if your user training on creating secure password phrases is working and will determine if passwords are being shared by administrator accounts, including accounts that administrators may have forgotten. If you want to know more about this service, please contact us using the form below or by clicking here.
