Most coverage of NIST's password guidance boils down to two headlines: no forced rotation, no mandatory composition rules. Both are real — What Makes a Strong Password Policy? covers why those two specifically reversed — but they're two provisions out of a much more specific document, one that also governs assurance levels, storage, rate limiting, and what a verifier is even allowed to ask you to remember. This is the section-by-section version, in NIST's own language.
Where memorized secrets fit: Authenticator Assurance Levels
NIST SP 800-63B doesn't call passwords "passwords" — the formal term is memorized secret, one of several authenticator types the document covers alongside hardware tokens, biometrics, and cryptographic keys. It organizes all of them under three Authenticator Assurance Levels:
- AAL1 — single-factor authentication is sufficient. A memorized secret alone satisfies this level.
- AAL2 — requires two distinct authentication factors (something you know plus something you have, typically). A password alone never reaches AAL2 — this is the formal reason MFA shows up throughout this site's own tools and guides as a separate, required layer rather than an optional add-on.
- AAL3 — requires a hardware-based authenticator and resistance to verifier impersonation. Out of scope for anything a memorized secret alone can satisfy.
Every requirement below governs memorized secrets specifically — the AAL1 piece of a larger system, not the whole authentication story by itself.
SHALL vs. SHOULD: why the wording matters
NIST documents use a specific, deliberate vocabulary (the same convention IETF RFCs use): SHALL and SHALL NOT are mandatory — a verifier that doesn't comply isn't implementing the standard, full stop. SHOULD and SHOULD NOT are strong recommendations you can deviate from only with a specific, documented reason. That distinction matters for reading the rest of this post: a couple of the most commonly cited "requirements" — permitting 64+ characters, checking against breached-password lists — are technically SHOULDs, while composition rules and forced rotation are the stronger SHALL NOT.
What verifiers SHALL do
- Enforce an 8-character minimum for subscriber-chosen memorized secrets (6 characters if the verifier or CSP generates it randomly using an approved random bit generator).
- Not impose composition rules — no mandatory mixtures of uppercase, lowercase, digits, and symbols.
- Not require periodic or arbitrary changes — a change is required only on evidence of compromise, or at the subscriber's own request.
- Verify the entire submitted secret — not a truncated prefix of it. See below for a real, specific tension this creates.
- Never store or display a password hint accessible to an unauthenticated party, and never prompt subscribers to choose a memorized secret based on knowledge-based authentication — "what was your first pet's name"-style security questions are explicitly out, not just discouraged.
- Rate-limit failed authentication attempts — an effective throttling mechanism against online guessing is mandatory, not optional hardening.
- Salt and hash stored secrets with a suitable one-way function — plaintext or reversibly-encrypted storage is a straightforward SHALL NOT.
What verifiers SHOULD do
- Permit at least 64 characters, ideally more — long enough that a passphrase or a password-manager-generated string never hits an arbitrary ceiling.
- Accept all printing ASCII characters, the space character, and Unicode — each Unicode code point counted as one character, with normalization applied so visually-equivalent representations of the same character are treated identically.
- Check new secrets against a list of values known to be compromised, commonly used, or otherwise predictable, and reject a match — the provision that gives Have I Been Pwned's Pwned Passwords k-anonymity API its standing as the reference real-world implementation.
- Offer strength guidance during creation, such as a strength meter — this site's own Password Entropy Calculator is exactly this kind of guidance, made standalone.
The truncation rule, and bcrypt's real tension with it
"Verify the entire secret" sounds obvious until you check what a specific algorithm actually does: bcrypt only processes the first 72 bytes of whatever password produced a given hash. Two passwords that agree on their first 72 bytes and differ only after that produce the identical bcrypt hash — a real, if narrow, gap against this specific NIST provision. Password Hash Inspector flags exactly this automatically on any bcrypt hash you paste in. In practice it rarely matters — 72 bytes covers any password a person could plausibly type — but it's worth knowing precisely because "OWASP-acceptable" and "fully 800-63B-compliant" aren't quite the same claim for this one specific algorithm. Argon2id and scrypt don't share this limit; see Bcrypt vs Argon2 for the rest of that comparison.
Storage, in NIST's own terms
The document's storage requirement is specific: memorized secrets SHALL be salted using a salt of at least 32 bits, generated by an approved random bit generator, and hashed with a suitable one-way key derivation function. The iteration count should be as large as the verification server can tolerate. An additional secret value known only to the verifier — a pepper, stored separately from the salt and hash, in a system like an HSM or secrets vault — MAY be used on top of this for further protection. This is the formal version of what Password Hashing Explained and Understanding Salt and Pepper cover in practical, implementation-level detail — Argon2id, bcrypt, and scrypt all satisfy this provision when configured at or above OWASP's current minimum parameters, which is a more specific, actively-maintained bar than the standard's own general "as large as tolerable" language.
FAQ
Is any of this legally mandatory for my company?
NIST SP 800-63B is mandatory for U.S. federal information systems and widely adopted elsewhere as best practice, but it isn't automatically binding on a private company — a specific contract, regulation, or compliance framework might impose its own requirements instead of or on top of it.
Does "SHOULD" mean a requirement is optional?
Not casually optional — a SHOULD is a strong recommendation the standard expects you to follow unless you have a specific, documented reason not to, not a suggestion to weigh equally against convenience.
Where's the line between this document and general security best practice?
This post covers what 800-63B itself specifies for memorized secrets. Practices like pepper (a MAY, not a SHALL) and specific per-algorithm cost parameters go beyond the standard's own general language into current best practice — see Password Hashing Best Practices for that layer.
Try it yourself
Password Policy Generator and Password Policy Validator check a policy against these exact provisions from either direction, and Password Storage Checker grades whether a system's actual storage and authentication practices meet them. All three run entirely in your browser.