Navigating the Impact of NIST 800-63B-4’s New Password Guidelines on Your Organization
NIST (National Institute of Standards and Technology), is an agency of the United States Department of Commerce, and as part of their mission they develop and apply technology, measurements, and standards to enhance economic security and improve quality of life. NIST plays a crucial role in helping the USA maintain its leadership in science and technology.
Previous publication: Digital Identity Guidelines: Authentication and Lifecycle Management (nist.gov)
Intercede have studied the latest draft of NIST SP 800-63B password guidance, in which significant changes have been considered. It is important to note that the document is in draft so may still change. However, it is vital to understand the changes and prepare to stay compliant.
A lot of the guidance is not new, but some terms within the guidance have changed from “should” to “shall”, effectively changing from we recommend you do this, to you have to adhere to this.
For instance, there is an increased reliance on password breach databases/blocklists, which includes a compromise detection. This is a fundamental change to the previous guidance of checking a password on change and closes a critical process gap from the previous guidance.
NIST have also changed the wording for “something you know” from “memorized secrets” to “password”, and this still covers all memorized secrets such as passphrases and PINs. Passwords are still accessible as a Single Factor (AAL1) or one of a Multi-Factor Authentication (AAL2 & AAL3) and NIST has made it quite clear that passwords are NOT phishing resistant.
The key proposed changes that will affect you if you are maintaining NIST compliance:
- Password Blocklists: The required use of password blocklists before accepting a new password (e.g. on password change) is not new and the guidance has actually not changed. However, additional information has been provided about the size of the database, simply put, bigger is better. NIST are clear that incremental security benefits do gradually diminish the larger the dataset gets, but there is no downside to more data. Note: Many password security products will significantly fail to meet this requirement.
- Compromise Detection: This is big! To quote NIST: “Verifiers and Cloud Service Providers (CSP’s) SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.” This is a critical new shall, that isn’t given as much attention and is almost listed as a footnote to banning periodic password changes.
So, the reasoning behind this one is likely to be that passwords should be changed to ensure that they remain a secret; that is a measure of their security. Password changes made based on a calendar may ensure they are not old, but it doesn’t ensure they are actually a secret. A password is no longer a secret if someone else knows what it is. So if the password ends up in a password breach database, it is no longer a secret. Conversely if a password has NOT appeared in a breach database, then the level of safety can be assumed to keep using it no matter how old it is. NIST only require a single piece of evidence of compromise to require a change but does not explicitly list type or number of locations to look for.
Compromise detection requires a system in place that can look for when a compromise occurs. Such a system would need to evaluate all your user’s passwords on a continuous basis, or at least check them each time a password is used. The check could be as simple as seeing if the existing password is in a breach database, much like when checking if a new password is safe to use. If the password is no longer safe, then the user must be forced to change their password. This poses a serious problem for most Active Directory users as it does not have such a feature out of the box, so to comply with NIST a 3rd party password security management tool is required.
- Password Length: A minimum password length, if chosen by a user, is still 8 characters, although 15 is now recommended. This same rule now applies to random generated passwords too and consistency here is a good thing.
- Password Complexity: Simply put, it is gone entirely now, so it’s time to untick that Active Directory require password complexity The reasoning for not doing complexity anymore is not new; there is no real-world value in making users do the uppercase + lowercase + special character dance. What is new is that you are now NOT allowed to do it, the optional part has been removed as the guidance has switched from should not to shall not, subtle but key.
- Password Expiry: This concept is also now a relic of times gone by so now it’s time to untick that Active Directory setting too as the updated guidance on this topic has switched from should not to shall not. A common misconception is that “a fresh password is a secure password”, well, not if the new one is in a breached password dump, but the old one isn’t. See Compromise Detection
- User assistance: Helping a user choose a compliant password is not just helpful, it is now a shall. “Strength meters” used to be recommended but are now in the bin as complexity rules are no longer permitted. However, guidance is still required for users, especially if they choose a password that has already been compromised and they don’t know why their shiny new password has been rejected.
- Password Resets: You may need to check your operational processes regarding password resets too as you may not set non-random passwords for a user anymore. A user shall choose their own password, or you shall set a random one for them, there is no plan C anymore. Plus, any random password must be at least 8 characters in length, up from the previous minimum of 6. See Length
All this is good news if you have MyID PSM, see below how we already enable you to comply with the updated NIST SP800-63B draft guidance.
NIST Requirement | In MyID PSM | Details |
Password Blocklists | Yes | MyID PSM integrates with the Intercede Password Breach Database containing over 3.2 billion unique breached passwords and is updated daily based on real-world breaches. Every password change is checked against this database in real-time with passwords never leaving the network. |
Compromise Detection | Yes | MyID PSM monitors Active Directory and checks all passwords up to every 4 hours for compromise. If found, the user is forced to change their password at their next login. Alerts, notifications, and reporting are included as standard. |
Length | Yes | The default value in MyID PSM is a minimum of 8 characters. Any minimum length can be selected. |
Complexity | Yes | MyID PSM has many granular complexity rules for various scenarios which are disabled by default for NIST compliance. |
Password Expiry | Yes | Passwords are set to never expire by default with MyID PSM. |
User assistance | Yes | Users are given granular feedback when changing or resetting their passwords with MyID PSM via a web browser or directly within Windows. |
As you navigate these updates to the NIST password guidelines, you might find yourself needing a bit more guidance or support. Why not see these changes in action? Request a demo and experience firsthand how our solutions can seamlessly align with the new standards and strengthen your organization’s security. Let us help you simplify compliance, improve security, and empower your team. Contact us today to schedule your demo.
Trusted by Governments and Enterprises Worldwide
Where protecting systems and information really matters, you
will find Intercede. Whether its citizen
data, aerospace and defence systems, high-value financial transactions,
intellectual property or air traffic control, we are proud that many leading
organisations around the world choose Intercede solutions to protect themselves
against data breach, comply with regulations and ensure business continuity.