What the 2017 NIST Password Guidelines Mean for Corporate Environments

Adrian Vargas
| 2/8/2018
What the 2017 NIST Password Guidelines Mean for Corporate Environments

Now that we in the technology community have had a few months with the finalized Special Publication (SP) 800-63B from the National Institute of Standards and Technology (NIST), let’s revisit and analyze parts of the digital identity guidelines that we continue to hear questions about.

In April 2017, my colleague, Mike Del Giudice, wrote about a number of the significant changes on this blog that spurred plenty of conversations and interpretations. While I won’t go into extreme technical detail about those changes in this post, I will try to simplify what the guidelines mean for your network infrastructure.

System and Application Sensitivity

First things first. Information exchanged in online transactions can be protected in different ways. For example, a low-risk system or application that is not dealing with any personally identifiable information (PII) or other sensitive personal data can simply require a password. A user can also stay logged in for 30 days of extended usage without having to reauthenticate.

However, when PII or other personal information is involved – that is, if the user is providing such information or the system or application is providing it – multifactor authentication must be used to secure the information. Additionally, the user will have to reauthenticate after 12 hours of activity or 30 minutes of inactivity by using at least one of the authentication factors.

Think about the typical internal network and the information accessible within it, and consider how many organizations have multifactor authentication enabled internally. Not very common, is it?

Password Guidance Changes

Perhaps the most talked about changes in the guidelines focus on the password requirements. Most notably, NIST is recommending that we as system and security engineers should not require passwords to follow complexity standards nor have expiration dates when users are forced to change them.

These two recommendations about complexity and expiration have sparked debates about whether companies can now escape from their Microsoft™ Active Directory™ password policies and allow users to keep their shorter passwords indefinitely.

Length and Complexity

Change is good, right? Well, first let’s talk about why it doesn’t make sense to eliminate length and complexity requirements in our Active Directory environments.

To get a little more technical: One of the requirements mandates that stored passwords must be salted before computing the hash. “Salting” means that an arbitrary value is combined with the user’s password before it can be converted into a hash and stored.

The goal of salting a password is to make the stored password more resistant to offline attacks. If done properly, two user passwords that are exactly the same will have two unique hashed values, which makes password cracking computationally more expensive and prevents an attacker from using rainbow tables to attack the hash.

What does this mean for Active Directory environments? Well, Microsoft Windows™ systems don’t use salts when generating password hashes, so we aren’t able to use this guidance to support staying at a minimum password length of eight characters.


So, why can’t we keep the same password without enforcing an expiration date in our Active Directory environments?

Periodic password changes are beneficial to help protect passwords that can potentially become compromised given the opportunity and time through online or offline password attacks.

For example, with online password guessing, an attacker has the time until a password expires to guess the correct password for a targeted account before the user changes it. With offline password cracking, the hope is that by the time an attacker successfully cracks the compromised password hash it is no longer valid due to the forced password change.

The NIST guidance requires that user-selected passwords be compared against a list of weak or previously compromised passwords and rejected if found within the list to help minimize the chances that the selected passwords can become compromised in the future.

While more organizations are beginning to use blacklists to restrict the use of certain passwords within the Active Directory environment, the practice – in our experience – is not widespread. Where it is used, we often still identify weak passwords, which suggests that the blacklists in use are not as restrictive as they should be.

What Does All This Mean?

The NIST’s digital identity guidelines are geared more toward applications rather than typical corporate infrastructure based on Windows systems. Considering that 1) system and application sensitivity dictate whether access should be authenticated with multiple factors; and 2) passwords should be verified against a blacklist and salted before being hashed, organizations should rely on strong passphrases that must be changed periodically for the foreseeable future.

Microsoft, Active Directory, and Windows are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.