NIST Password Guidelines Breakdown

Introduction
Recommendation Grades
Password Authentication Standards
Commentary
Appendix

Authenticator Assurance Level
Omitted Guidelines
Further Reading

Introduction

In June 2017, the U.S. Department of Commerce's National Institute of Standards and Technology quietly issued a revision of their Digital Identity Guidelines publication which provided the required password authentication guidelines to be followed by Federal agencies.

Noted for its salient advice contradicting harmful contemporary dogma — namely: complexity requirements, knowledge based authentication, password hints, and forced periodical change — the updated guidelines represent an effective standard to follow for any consumer-facing website's password registration and authentication process.

Unable to find a comprehensive summary of the relevant NIST publication sections (5.1.1 - 5.1.2), one has been provided one here. The guidelines listed should be considered best practices to follow for any standard web service requiring basic password authentication.

Recommendation Grades

It's important to understand NIST delineates four graded standards of recommendation:

SHALL/SHALL NOT: Requirements to be strictly followed and from which no deviation is permitted.
SHOULD/SHOULD NOT: Recommendations considered particularly suitable but not specifically in exclusion of alternativess, or that a certain course of action is preferred/discouraged but not necessarily required/prohibited.
MAY/NEED NOT: Permissible courses of action as far as the NIST Guidelines is concerned, but not necessarily recommended.
CAN/CANNOT: Anything that is/is not possible.

NIST also delineates three grades of Authenticator Assurance requiring various levels of authentication as well as many different kinds of authentication protocols. However, for the purposes of this article, we will be focusing solely on AAL1, the lowest level, and memorized secret (hereafter, password) authentication.

Password Authentication Standards

Restrictions

A password SHALL be required to be at least 8 characters in length.
All passwords SHALL be compared against a blacklist of compromised passwords, which MAY include but is not limited to:
1. Passwords obtained in breach corpuses.
2. Common dictionary words.
3. Repetitive or sequential characters
4. Context-specific words.
If the password is found on the list, the verifier SHALL provide the reason for rejection and the user SHALL be required to select a different password.
No other complexity requirements SHOULD be imposed.

Allowances

A password SHOULD be permitted to be at least 64 characters in length.
All ASCII, Unicode and the space character SHOULD be permitted.
The user SHOULD be permitted to use paste functionality when entering a password, to facilitate the use of password managers.
Passwords SHOULD NOT be required to be changed arbitrarily (e.g. periodically). However, passwords SHALL be forced to change if there is evidence of a compromise.
The user SHOULD be offered an option to display the password, instead of a series of dots or asterisks, to facilitate entering the password.
The user MAY be permitted the option for the user's device to display individual characters as they are entered, to facilitate mobile devices.
The user SHOULD be offered guidance to assist the user in choosing a strong password, such as a password-strength meter.
The user SHALL NOT be permitted to provide a publicly accessible "hint".
The user SHALL NOT be prompted to use Knowledge Based Authentication (e.g., “What was the name of your first pet?”) for authentication or password recovery.

Commentary

The resolutely short list of restrictions stands in stark contrast to the misguided and user-negative policy of extensive forced complexity (e.g., 1 uppercase letter, 1 number, 1 special character, etc.) and arbitrary change (e.g., periodical) we find common today (ironically, in large part due to previous NIST guidelines). The authors offer a firm justification for their recommendations in a highly readable appendix.

In short, complexity requirements are counter-productive. Forcing users to change provided passwords to be more complex results in predictable modifications to their existing vulnerable password, a concept known as munging. And it's well documented that munged passwords are easily cracked and a standard consideration of any hacker. It results in a false sense of security especially as it tends to receive erroneously high rating by most password strength meters.

From the paper itself:

Humans... have only a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed. To address the resultant security concerns, online services have introduced rules in an effort to increase the complexity of these memorized secrets. The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought, although the impact on usability and memorability is severe.

In contrast, length, blacklisting and proper server-side cryptography is more than sufficient to mitigate against brute-force attacks.

The authors summarize their position succintly at the end of the referenced appendix:

Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blacklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed.

Authenticator Assurance Level

NIST delineates three grades of Authenticator Assurance:

Authenticator Assurance Level 1: AAL1 provides "some assurance," requiring single or multi-factor authentication that requires the claimant to prove possession and control of the authenticator through a secure authentication protocol.
Authenticator Assurance Level 2: AAL2 provides "high confidence," requiring proof of possession and control of two different authentication factors through a secure authentication protocols. Approved cryptographic techniques are required at AAL2 and above.
Authenticator Assurance Level 3: AAL3 provides "very high confidence," requiring proof of possession of a key via a hardware-based authenticator and authenticator that provides verifier impersonation resistance, and prove possession and over two distinct authentication factors.

Omitted Guidelines

Some guidelines included in the 5.1.2 Section were omitted from the Password Guidelines due to length and irrelevancy to the goals of this article. They are included in full below:

Regarding Text Formatting

If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings using either the NFKC or NFKD normalization. This process is applied before hashing the byte string representing the memorized secret. Subscribers choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully.
The verifier MAY replace multiple consecutive space characters with a single space character to make allowances for mistypings, provided that the result is at least 8 characters. However, the truncation of the password itself SHALL NOT be performed.

Regarding Server-side Security

The verifier SHALL use approved encryption and an authenticated protected channel when requesting memorized secrets to protect against eavesdropping and MitM attacks.
Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive. Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) and Balloon. A memory-hard function SHOULD be used because it increases the cost of an attack. The key derivation function SHALL use an approved one-way function such as Keyed Hash Message Authentication Code (HMAC), any approved hash function in SP 800-107, Secure Hash Algorithm 3 (SHA-3), CMAC or Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash. The chosen output length of the key derivation function SHOULD be the same as the length of the underlying one-way function output.
The salt SHALL be at least 32 bits in length and be chosen arbitrarily so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each subscriber using a memorized secret authenticator.
For PBKDF2, the cost factor is an iteration count: the more times the PBKDF2 function is iterated, the longer it takes to compute the password hash. Therefore, the iteration count SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations.
In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier. This salt value, if used, SHALL be generated by an approved random bit generator and provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The secret salt value SHALL be stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module). With this additional iteration, brute-force attacks on the hashed memorized secrets are impractical as long as the secret salt value remains secret.