The most basic form of authentication is the password. Despite many advancements in cybersecurity, the username and password, although outdated, are still used as the most common form of authentication today. Enterprise environments have long used password policies to help enforce password rules to help minimize the use of weak passwords.
However, Active Directory fine-grained password policies lack the features needed to implement modern cybersecurity authorities’ recommendations for password policy best practices. One such authority is the National Institute of Standards and Technology (NIST). The latest guidance provided by NIST provides many different components to recommended password policy. What are those? How can organizations easily align their password policies to include the recommended best practices?
What is NIST 800-63b?
The National Institute of Standards and Technology (NIST) Special Publication 800-63B Digital Identity Guidelines provide best practices related to authentication and password lifecycle management. In this publication, NIST outlines several best practices to bolster their password security. Let’s take a look at the following NIST recommendations related to end-users changing their passwords:
- Check passwords against breached password lists
- Block passwords contained in password dictionaries
- Prevent the use of repetitive or incremental passwords
- Disallow context-specific words as passwords
- Increase the length of passwords
Do the Active Directory Password Policy settings protect organizations from the recommendations as outlined by NIST?
Implementing NIST 800-63B Digital Identity Guidelines
1. Check passwords against breached password lists
In the NIST Digital Identity Guidelines, it mentions:
“when processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:
- Passwords obtained from previous breach corpuses.”
It means that by today’s standards, organizations should check the passwords chosen by end-users against breached password databases or lists. This process helps prevent end-users from picking a password that has already appeared in a database of breached passwords compromised in previous attacks.
We, as humans, tend to think alike. If one person thinks of a specific password, the odds are that another unrelated end-user may think of the same password somewhere else. In addition, end-users tend to use the same passwords between personal and business accounts and use the same password between multiple services. Our Specops Password Auditor identical passwords report identifies groups of user accounts that have the same password. Not preventing common passwords is a common reason why users end up on that report.
Hackers are heavily using breached password databases in brute force and password spraying attacks to compromise business environments. For example, the attack on Colonial Pipeline is now thought to have resulted due to one breached password that was part of a database of some 8 billion passwords on the dark web. It is believed the Colonial employee may have used the same password on another account that was hacked previously. It helps to see the tremendous damage resulting from a breached password that hackers find using a breached password database.
As defined in Group Policy, Active Directory Password Policy has no native way to check for breached passwords in the environment. PowerShell scripts are widely available that can help check Active Directory against small lists of breached passwords. However, these are usually not actively supported and may not contain an entire subset of breached passwords to match.
Organizations must use effective third-party breached password protection in their Active Directory environments to find end-user passwords that may already be on breached lists and warn them if a set password becomes breached at a later time.
2. Block passwords contained in password dictionaries
Similar in concept is using what is known as a password dictionary to filter or disallow specific passwords from being used by end-users. Password dictionaries can be effective since they can contain words that are specific to the organization or business. Attackers often try combinations of passwords that may contain elements that relate to the business. For example, end-users tend to use passwords containing the business name, well-known products, or other easily guessable words.
Using a custom password dictionary allows companies to configure large sets of custom words and variations of those words as disallowed for use in a password. Active Directory does have a way to use password filter .dll files that can implement these lists of disallowed passwords.
However, businesses must write the .dll files themselves and make sure these are implemented correctly. Many companies may not have in-house developers, so this can be a challenge. As a result, third-party solutions are generally needed to implement custom password dictionaries adequately.
3. Prevent the use of repetitive or incremental passwords
Another typical end-user behavior when choosing passwords when required to change is choosing repetitive or sequential characters. For example, when businesses use password expiration thresholds in the Active Directory environment, end-users may simply change their password by placing a sequential number on the end. NIST 800-63B recommends checking passwords for Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
For example, if an end-user password is currently P@$$word1 in Active Directory (a weak password to begin with), they may be inclined when forced to change their password to increment the password by changing it to P@$$word2. The reason for this is simple. Active Directory complexity requirements and Password history settings found in traditional Active Directory Password Policies do not prevent simply incrementing passwords.
4. Disallow context-specific words as passwords
Another common component of a weak password is a password that contains part of the username or other context-specific components, such as part of the user’s full name. Organizations need to block the use of context-specific password components and make sure users choose non-context-specific passwords. According to NIST, the following should be checked when end-user passwords are configured:
- Block Context-specific words, such as the name of the service, the username, and derivatives thereof
The Active Directory Password Policy Password complexity rule enforces the following:
- Password must not contain the user’s account name or parts of the user’s full name that exceed two consecutive characters
- It should be at least six characters in length
- It must contain characters from three of the following four categories:
- English uppercase characters (A through Z)
- English lowercase characters (a through z)
- Base 10 digits (0 through 9)
- Non-alphabetic characters (for example, !, $, #, %)
- Complexity requirements are enforced when passwords are changed or created.
However, there are other password content restrictions that organizations may want to enforce to help ensure strong passwords and that help to protect against common patterns that attackers target. These include:
- Using a digit as the first character in a password
- Using a digit as the last character in a password
- Disallow consecutive identical characters
The above rules are not enforceable using the native Active Directory Password Policy settings. Organizations must use third-party solutions to enforce these additional password content restrictions. Shorter passwords are much easier to brute force and are more likely to be cracked by dictionary attacks.
5. Increase the length of passwords
Increased password length is more important than complexity when it comes to password security. According to the NIST Special Publication 800-63B, password length has been found to be a primary factor in characterizing password strength. NIST password length requirements are thatall user-created passwords be at least 8 characters in length and all machine-generated passwords are at least 6 characters in length.
While online attacks can be limited to some extent by “rate-limiting” password attempts or account lockouts, it does not protect against offline attacks where an attacker is able to compromise a database filled with hashed passwords. In this case, attackers can perform billions of guesses per second with no rate limiting in these offline types of attacks. In this case, longer passwords are much more important for protecting against compromise.
Organizations should encourage their users to make passwords as lengthy as they want. Pass phrases are a great way to increase the length of passwords used and provides an easy way to remember the passwords chosen.
Specops Password Policy and Password Auditor
As mentioned, the native Active Directory Password Policy settings lack several vital areas of password enforcement recommended by NIST and other cybersecurity authorities. As a result, third-party solutions are required to align Active Directory password policies with current recommendations.
Specops Password Policyand Specops Password Auditor are tools that allow businesses to take control of Active Directory Password Policies and ensure these meet with best-practice standards. In addition, Specops Password Policy enables organizations to add the missing features in their organization’s password policies, including:
- Breached password protection
- Custom password dictionaries
- Blocking repetitive or incremental passwords
- Disallow context-specific words as passwords
- Increase the length of passwords
Specops Breached Password Protection now includes live attack data that continuously detects breached passwords used in actual breach events. It also checks a database of over 3 billion breached passwords and enables checking passwords against the breached password list when users change their passwords.
