All Systems Engineers, Administrators, Security Engineers, Information Security Consultants are worried most of the time on the password policies and the impact that may affect the entire organizations security. And they are absolutely right to worry about this more than anything else as you internals security these days are more worrying factor over the external ones.
You could have the best firewall solutions in place, you may had IPS/IDS, you may had the best NAC/NAP solutions implemented, PKI, encryption, bitlocker … etc. you name it!! Always consider if this any of these walls break, the next step for the attack is to take control over your resources by authenticating, which will require a user and password, once a privileged account’s password compromised, the pain starts.
In this article I will consider talking about field challenges to implement a balanced password policies between Maximum Security, business requirements and the ease of use in acceptable level.
Let us first look at the various attributes of domain password policies as per the best practices:
Attribute | Microsoft Default Value | Microsoft Recommended Value |
Account lockout threshold | 0 | 50 |
Reset account lockout counter after | 0 | 15 minutes |
Account lockout duration | Not defined | 15 minutes |
Minimum password length | 0 | 12 characters |
Password must meet complexity requirements | Disabled | Enabled |
Maximum password age | 42 days | 90 days |
Minimum password age | 0 | 1 day |
Enforce password history | 24 days | 24 days |
In the above table, these are the settings that you will see in the default domain policy in addition to the recommended values that Microsoft recommends to you to stay secure. The aim of the rough recommended values is to make you secure is in it? Although this remains a challenge to implement such strict recommendation.
All password policy attributes in the above table classified as “Critical” in severity risk classification as each one of these attributes has a vulnerability and countermeasures behind it. Not only that, the value combination plays a role on how each setting will affect other setting as they are fairly and strictly related, all these values in sum will define how far your password policy is security oriented.
To make it easier, I will assume that the readers of this article know what each password attribute means, in case u are not sure please follow this link for description of each attribute: http://technet.microsoft.com/en-us/library/hh994572(v=ws.10).aspx
Now for each attribute, I will highlight each vulnerability, counter measures and potential impact.
Account lockout threshold
- Vulnerability: If a bruit force attack targeted a user, this setting will minimize the number of attack attempts where after certain number of failed attempt the account will lock, however, a DoS attack can be performed across the domain by an attacker trying a series of password attacks against all domain users (don’t forget that Active Directory objects are readable by design for all authenticated users!!), if the number of attempts is greater than the lockout value, a Denial of users logon ability will take place.
- Countermeasures: When the lockout value exists, a vulnerability to DoS may occur as described in the vulnerability. Here are some strong recommendation to overcome this vulnerability at the best:
o Configure the Account Lockout Threshold setting to 0. This configuration ensures that accounts will not be locked out, and will prevent a DoS attack that intentionally attempts to lock out accounts. This configuration also helps reduce help desk calls because users cannot accidentally lock themselves out of their accounts. Because it will not prevent a brute force attack, this configuration should only be chosen if both of the following criteria are explicitly met:
1. The password policy requires all users to have complex passwords of 8 or more characters.
2. A strong audit methodology(s) is in place (e.g. SCOM ACS) to alert systems engineers when a failed logons occur in the environment.
o Configure the Account Lockout Threshold setting to a high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack will still lock the account. A good recommendation for such a configuration is 50 invalid logon attempts, which will prevent accidental account lockouts and reduce the number of help desk calls but will not prevent a DoS attack (as discussed earlier). This option is recommended if your organization does not have complex password requirements and an audit policy that alerts administrators to a series of failed logon attempts.
- Potential impact: If this policy setting is enabled, a locked-out account will not be usable until it is reset by an administrator or until the account lockout duration expires. This setting will likely generate a number of additional help desk calls. In fact, locked accounts cause the greatest number of calls to the help desk in many organizations. If you enforce this setting an attacker could cause a denial of service condition by deliberately generating failed logons for multiple user, therefore you should also configure the Account Lockout Duration to a relatively low value such as 15 minutes. If you configure the Account Lockout Threshold to 0, there is a possibility that an attacker’s attempt to discover passwords with a brute force password attack might go undetected if a robust audit mechanism is not in place.
Reset account lockout counter after
- Vulnerability: Users can accidentally lock themselves out of their accounts if they mistype their password multiple times. To reduce the chance of such accidental lockouts, the Reset account lockout counter after setting determines the number of minutes that must elapse before the counter that tracks failed logon attempts and triggers lockouts is reset to 0.
- Countermeasures: Configure the Reset account lockout counter after setting to 15 minutes.
- Potential impact: If you do not configure this policy setting or if the value is configured to an interval that is too long, a DoS attack could occur. An attacker could maliciously attempt to log on to each user’s account numerous times and lock out their accounts as described in the preceding paragraphs. If you do not configure the Reset account lockout counter after setting, administrators would have to manually unlock all accounts. If you configure this policy setting to a reasonable value the users would be locked out for some period, after which their accounts would unlock automatically. Be sure that you notify users of the values used for this policy setting so that they will wait for the lockout timer to expire before they call the help desk about their inability to log on.
Account lockout duration
- Vulnerability: A denial of service (DoS) condition can be created if an attacker abuses the Account lockout threshold and repeatedly attempts to log on with a specific account. Once you configure the Account lockout threshold setting, the account will be locked out after the specified number of failed attempts. If you configure the Account lockout duration setting to 0, then the account will remain locked out until an administrator unlocks it manually.
- Countermeasures: Configure the Account lockout duration setting to an appropriate value for your environment. To specify that the account will remain locked until an administrator manually unlocks it, configure the value to 0. When the Account lockout duration setting is configured to a non-zero value, automated attempts to guess account passwords must wait for this interval before they resume attempts against a specific account. Using this setting in combination with the Account lockout threshold setting makes automated password guessing attempts more difficult.
- Potential impact: Although it may seem like a good idea to configure this policy setting to never automatically unlock an account, such a configuration can increase the number of requests that your organization’s help desk receives to unlock accounts that were locked by mistake.
Minimum password length
- Vulnerability: Types of password attacks include dictionary attacks (which attempt to use common words and phrases) and brute force attacks (which try every possible combination of characters). Also, attackers sometimes try to obtain the account database so they can use tools to discover the accounts and passwords.
- Countermeasures: Configure the Minimum password length setting to a value of 8 or more. If the number of characters is set to 0, no password will be required. In most environments, we recommend an 8-character password because it is long enough to provide adequate security but not too difficult for users to easily remember. This configuration provides adequate defense against a brute force attack. Using the Passwords must meet complexity requirements setting in addition to the Minimum password length setting helps reduce the possibility of a dictionary attack. Note Some regions have legal requirements with respect to password length.
- Potential impact: Requirements for extremely long passwords can actually decrease the security of an organization, because users might leave the information in an insecure location or lose it. If very long passwords are required, mistyped passwords could cause account lockouts and increase the volume of help desk calls. If your organization has issues with forgotten passwords due to password length requirements, consider teaching your users about pass phrases, which are often easier to remember and, due to the larger number of character combinations, much harder to discover. Note Older versions of Windows such as Windows 98 and Windows NT® 4.0 do not support passwords that are longer than 14 characters. Computers that run these older operating systems are unable to authenticate with computers or domains that use accounts that require long passwords.
Password must meet complexity requirements
- Vulnerability: Passwords that contain only alphanumeric characters are extremely easy to discover with several publicly available tools.
- Countermeasures: When combined with a Minimum password length of 8, this policy setting ensures that the number of different possibilities for a single password is so great that it will be difficult (but not impossible) for brute force attack to succeed. (If the Minimum password length setting is increased, the average amount of time necessary for a successful attack also increases).
- Potential impact: If the default password complexity configuration is retained, additional help desk calls for locked-out accounts could occur because users might not be accustomed to passwords that contain non-alphabetic characters. However, all users should be able to comply with the complexity requirement with minimal difficulty. If your organization has more stringent security requirements, you can create a custom version of the Passfilt.dll file that allows the use of arbitrarily complex password strength rules. For example, a custom password filter might require the use of non-upper row characters. (Upper row characters are those that require you to hold down the SHIFT key and press any of the digits between 1 and 0.) A custom password filter might also perform a dictionary check to verify that the proposed password does not contain common dictionary words or fragments. Also, the use of ALT key character combinations can greatly enhance the complexity of a password. However, such stringent password requirements can result in unhappy users and an extremely busy help desk. Alternatively, your organization could consider a requirement for all administrator passwords to use ALT characters in the 0128–0159 range. (ALT characters outside of this range can represent standard alphanumeric characters that would not add additional complexity to the password).
Maximum password age
- Vulnerability: The longer a password exists the higher the likelihood that it will be compromised by a brute force attack, by an attacker gaining general knowledge about the user, or by the user sharing the password. Configuring the Maximum password age setting to 0 so that users are never required to change their passwords is a major security risk because that allows a compromised password to be used by the malicious user for as long as the valid user is authorized access.
- Countermeasures: Configure the Maximum password age setting to a value that is suitable for your organization’s business requirements. When configuring this setting you should also configure the Minimum password age to a value that makes sense in combination with this one.
- Potential impact: If the Maximum password age setting is too low, users are required to change their passwords very often. Such a configuration can reduce security in the organization, because users might write their passwords in an insecure location or lose them. If the value for this policy setting is too high, the level of security within an organization is reduced because it allows potential attackers more time in which to discover user passwords or to use compromised accounts.
Minimum password age
- Vulnerability: Users may have favorite passwords that they like to use because they are easy to remember and they believe that their password choice is secure from compromise. Unfortunately, passwords are compromised and if an attacker is targeting a specific individual user account, with foreknowledge of data about that user, reuse of old passwords can cause a security breach. To address password reuse a combination of security settings is required. Using this policy setting with the Enforce password history setting prevents the easy reuse of old passwords. For example, if you configure the Enforce password history setting to ensure that users cannot reuse any of their last 12 passwords, they could change their password 13 times in a few minutes and reuse the password they started with, unless you also configure the Minimum password age setting to a number that is greater than 0. You must configure this policy setting to a number that is greater than 0 for the Enforce password history setting to be effective.
- Countermeasures: Configure the Minimum password age setting to a value of at least 2 days. Users should know about this limitation and contact the help desk if they need to change their password during that 2-day period. If you configure the number of days to 0, immediate password changes would be allowed, which we do not recommend. When configuring this setting you should also configure the Maximum password age to a value that makes sense in combination with this one.
- Potential impact: If an administrator sets a password for a user but wants that user to change the password when the user first logs on, the administrator must select the User must change password at next logon check box, or the user will not be able to change the password until the next day.
Enforce password history
- Vulnerability: The longer a user uses the same password, the greater the chance that an attacker can determine the password through brute force attacks. Also, any accounts that may have been compromised will remain exploitable for as long as the password is left unchanged. If password changes are required but password reuse is not prevented, or if users continually reuse a small number of passwords, the effectiveness of a good password policy is greatly reduced. If you specify a low number for this policy setting, users will be able to use the same small number of passwords repeatedly. If you do not also configure the Minimum password age setting, users might repeatedly change their passwords until they can reuse their original password.
- Countermeasures: Configure the Enforce password history setting to 24, the maximum setting, to help minimize the number of vulnerabilities that are caused by password reuse. For this setting to be effective in your organization, do not allow passwords to be changed immediately when you configure the Minimum password age setting. The Enforce password history value should be set at a level that combines a reasonable maximum password age with a reasonable password change interval requirement for all users in your organization.
- Potential impact: The major impact of this configuration is that users must create a new password every time they are required to change their old one. If users are required to change their passwords to new unique values, there is an increased risk of users who write their passwords somewhere so that they do not forget them. Another risk is that users may create passwords that change incrementally (for example, password01, password02, and so on) to facilitate memorization but make them easier to guess. Also, an excessively low value for the Minimum password age setting will likely increase administrative overhead, because users who forget their passwords might ask the help desk to reset them frequently.
All the above recommendation are based on studies and analysis of real scenarios where your password policy pain points will suffer from. All the recommendations tackles variety of scenarios where you may consider to maximize the security along with ease of use (in a reasonable way).
Business requirements always play a main role, as security personnel, we always aim to maximize the security practices, this article helps you to guide a well-balanced approach on what could be done to achieve an acceptable level in security and make it aligned with the business needs and requirements.
Putting all together
Based on all of the above, I will give some examples where you can balance, compromise security in some settings where you still cover it in some others, these are just two examples, combinations could go to high number certainly, the examples just to make it easy to compile all the passwords attributes vulnerabilities, countermeasure and potential impact and put them all together in one big understanding vision
Example 1
Attribute | Value | Why |
Account lockout threshold | 40 | Only if you will disable the complexity and lockouts auditing is enabled |
Reset account lockout counter after | 15 | Reduce helpdesk calls and will avoid resetting the counter to Account lockout threshold 0. This setting always recommended to be 15 minutes in any password attributes combination |
Account lockout duration | 15 | Always same value as Reset account lockout counter after |
Minimum password length | 8 – 12 | When you have Account lockout threshold set to high number, a length of 8 and above will be sufficient |
Password must meet complexity requirements | Disabled | When the Account lockout threshold is more than 40, you can disable |
Maximum password age | 90 | This value is important to decrease the password where time frame of attack will be decreased, the lower value, the minimum surface attack will be. 90 days is the maximum value I recommend. |
Minimum password age | 1 | 1 day is the minimum in any case of attribues value combination, don’t ever put it 0, as this will make the password history obsolete, increasing it to more than 1 day is recommended optional |
Enforce password history | 24 days | 24 is the recommended in any passwords attributes combinations, and there is no point to decrease it, why would a user re-use an old password again? Re-using passwords will increase the surface attacks for brute attackers where the guessing possibilities are easier. |
Example 2
Attribute | Value | Why |
Account lockout threshold | 0 | Only if you will Enable the complexity and minimum password length is 8 or higher, in addition to auditing of wrong passwords attempts usage |
Reset account lockout counter after | 15 | Reduce helpdesk calls and will avoid resetting the counter to Account lockout threshold 0. This setting always recommended to be 15 minutes in any password attributes combination |
Account lockout duration | 15 | Always same value as Reset account lockout counter after |
Minimum password length | 6 – 8 | When you have Account lockout threshold set to 0, a length of 6 to 8 with Password must meet complexity requirements enabled is a must to decrease the possibility of brute force attack surface (not impossible) |
Password must meet complexity requirements | Enabled | When the Minimum password length is equal or higher than 8, this settings is still highly recommended to balance security and make it difficult to brute force attach (not impossible) |
Maximum password age | 90 | This value is important to decrease the password where time frame of attack will be decreased, the lower value, the minimum surface attack will be. 90 days is the maximum value I recommend. |
Minimum password age | 1 | 1 day is the minimum in any case of attributes value combination, don’t ever put it 0, as this will make the password history obsolete, increasing it to more than 1 day is recommended optional |
Enforce password history | 24 days | 24 is the recommended in any passwords attributes combinations, and there is no point to decrease it, why would a user re-use an old password again? Re-using passwords will increase the surface attacks for brute attackers where the guessing possibilities are easier. |
I hope this article were helpful and informative for you, please feel free to comment, add or ask if you find you may need any help.
Thank you J