Build a NIST 800-63B Compliant Password Policy in 1 Hour

In today’s world, password security is essential for every organization. A robust password policy can prevent unauthorized access, protect confidential data, and ensure compliance with industry standards. In this article, we provide guidance on implementing a password policy that complies with the National Institute of Standards and Technology (NIST) 800-63B guidelines. These guidelines are widely accepted as the industry standard for password security and provide a comprehensive framework for creating secure passwords.

By following these guidelines, you can ensure that your organization’s passwords are strong, secure, and less vulnerable to unauthorized access.

NIST 800-63B password conditions

Here is a list of the current password conditions recommended by NIST:

• Password Length – The minimum password length is at least 8 characters. Passwords with shorter lengths should be avoided. Users are encouraged to utilize passphrases instead of passwords.
• Prospective passwords – Passwords are compared against password breach databases and rejected if there is a match. Existing passwords found in the compromised database will be reset.
• Sequential Characters – Users cannot use 4 sequential characters (e.g., “abcd, 1234”).
• Repetitive Characters – Passwords may not contain 4 repetitive characters (e.g., “AAAA, !!!!, 1111”)
• Context-Specific Words – Passwords may not contain context-specific words. Such as the name of the user, the name of the service, the name of the company, the word password, or similar derivatives such as P@ssword.
• Password Complexity – Passwords do not require any combination of characters or special characters.
• Password Rotation – Passwords do not expire, but they can be changed whenever a user desires. Passwords are forced to be changed if there is a considerable risk of compromise.
• Password History – Users will not be allowed to use the same password as the last 10 previous passwords. The system will remember the last 4 passwords and prevent the user from reusing them.

With the requirements outlined above, NIST aims to encourage users and administrators to transition from single-word passwords to passphrases. Please refer to the informative chart below for more information.

Policy Implementation Walk through for Active Directory.

First, let’s complete all the policy settings that can be configured natively within Windows.

To enforce password history with a group policy object (GPO), navigate to Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Password Policy and enable the setting for “Enforce password history”.

To set the minimum password length in a GPO, navigate to Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Password Policy and enable the setting for “Minimum password length”. Set the value to 8 or higher.

To set the account lockout duration in a GPO, navigate to Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy and enable the setting for “Account lockout duration”. Set the value to your desired duration in minutes.

To set the account lockout threshold in a GPO, navigate to Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy and enable the setting for “Account lockout threshold”. Set the value to your desired number of invalid login attempts before the account is locked out.

To reset the account lockout counter after a certain period of time in a GPO, navigate to Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy and enable the setting for “Reset account lockout counter after”. Set the value to your desired duration in minutes.

When you have completed your policy, it should look similar to this.

In order to be in compliance with the following 4 items we will need to utilize a non-native software called Lithnet AD.

• Prospective passwords – Passwords are compared against password breach databases and rejected if there is a match. Existing passwords found in the compromised database will be reset.
• Sequential Characters – Users cannot use 4 sequential characters (e.g., “abcd, 1234”).
• Repetitive Characters – Passwords may not contain 4 repetitive characters (e.g., “AAAA, !!!!, 1111”)
• Context-Specific Words – Passwords may not contain context-specific words. Such as the name of the user, the name of the service, the name of the company, the word password, or similar derivatives such as P@ssword.

Lithnet AD is a free and opensource software built to enhance authentication in Active Directory. You can view their project on github. To install Lithnet, download and run the executable from their releases page here.

First we will build our compromised password store. Each server will have it’s own copy of the store that is replicated with DFS-R to keep changes in sync and always available. (If you aren’t sure how to set up a DFS-R store read this article) Create a new folder and add permissions for system and domain controllers to have read access to the share.

Caution: Do NOT put the folder in sysvol or netlogon.

Now that we have created the compromised password store, we can populate it with data from the HaveIBeenPwned API. To do so, turn off DFS-R Replication and run the following command:

Import-Module LithnetPasswordProtection
Open-Store -Path "D:\\password-protection\\store"
Sync-HashesFromHibp

You can also import any plain-text password lists to which you have access. This can be done using the Import-CompromisedPasswords cmdlet.

Import-CompromisedPasswords -Filename "D:\\password-protection\\hashes.org-2018.txt"

If you have individual passwords that you want to add, you can use the Add-CompromisedPassword cmdlet.

Add-CompromisedPassword -Value p@ssw0rd

The password filter can protect against common substitutions by normalizing incoming passwords and checking them against the banned word store. Normalization rules can be customized to prevent variations of banned words from being used. For example, adding lithnet to the banned word store will prevent variations such as lithnet2018, l1thn3t, and Lithnet!. You can learn more about the normalization rules to understand how they work in more detail.

The banned word store contains a list of words that should not be used in passwords. You can load common names in your organization, or load the entire dictionary. Use the Import-BannedWords cmdlet to import a file of newline-separated words.

Import-BannedWords -Filename "D:\\password-protection\\english-dictionary-words.txt"

To add individual words use the Add‐BannedWord cmdlet

Add-BannedWord -Value "lithnet"

Now that passwords have been added to the store, it’s time to create a password policy. Begin by creating a new GPO to link to the OU containing your domain controllers in Active Directory. If you have other computers that require the Get-PasswordFilterResult cmdlet, you must apply the group policy to them as well.

Note that Active Directory will still process its own password policy rules. Therefore, ensure that the built-in Active Directory password policy settings do not conflict with the Lithnet Password Protection (LPP) settings that you have set. For example, if you are using password complexity settings in LPP, it is recommended to disable Active Directory’s complexity settings.

The group policy settings are found under Computer Configuration\\Policies\\Administrative Templates\\Lithnet\\Password Filter. These are the settings I’ve used in my test domain.

Once you have completed these steps, you are done! Reboot your domain controllers and test Lithnet. After a reboot, Lithnet will show up in the application log of domain controllers with Event ID: 3.

Auditing existing passwords using this tool is not covered in this article, but a guide containing a pre-written script can be found here. If you encounter any issues, Lithnet has excellent documentation for testing, auditing, FAQs, and more. In fact, their documentation was used to write this article.

Thank you for reading! If you have been following along, you should now have a password policy that is 100% compliant with NIST 800-63B. If you need any assistance with the steps in this article or with other cybersecurity projects, feel free to email professionalservices@tridentstack.com.

If you are interested in an MDR, check out our demo at https://tridentstack.com/demo.