Password Security in 2026: What NIST Actually Recommends
NIST now says long, random, checked against breaches beats C0mpl3x! rules. Build a 2026-proof password strategy that humans can actually follow.
Generates cryptographically secure random passwords with custom length and character sets, locally on your device.
generate strong passwords following NIST guidelines →The myth of the complex eight-character password
Composition rules were a 1990s and 2000s artefact. Requiring a mix of uppercase, lowercase, digits and symbols does not produce a hard password, because the person choosing it responds predictably: capitalise the first letter, append a year, finish with an exclamation mark. The result is a small, highly structured candidate set that cracking tooling can enumerate far faster than the character count suggests. The same applies to substitution tricks. P@ssw0rd is not harder than Password; it is one more transformation rule a dictionary already contains. Bits make the point cleanly. Eight characters from the 94 printable ASCII characters carry about 52 bits, so a determined offline attack on a leaked hash is a matter of time and hardware. Sixteen characters from the same alphabet carry about 105 bits, which is a different problem. Length moves the number faster, and it is the one a human can follow without writing the password down.
What SP 800-63B-4 actually requires
The current revision is NIST SP 800-63B-4, published in July 2025, superseding the 2020 edition. Its memorable-secret section is short and specific. Verifiers SHALL require passwords used as a single-factor mechanism to be at least 15 characters, and MAY allow shorter ones, but not below 8, when they form only part of a multi-factor flow. Verifiers SHALL NOT impose other composition rules and SHALL NOT require periodic changes. When establishing or changing a password, verifiers SHALL compare the whole secret against a blocklist of commonly used, expected or compromised values, and SHALL tell the subscriber why it was rejected. Verifiers SHOULD permit at least 64 characters, SHOULD accept all printing ASCII and the space character, and SHOULD accept Unicode, counting each code point as one character. Secrets must be stored so they resist offline attack, using memory-hard or iterated key derivation rather than a bare hash. Note what is absent: no mandated symbol classes, no rotation schedule, no security questions. Passwords SHALL be chosen by the subscriber or assigned randomly by the provider, and a random one must come from an approved random bit generator.
How long is long enough, in bits
Entropy is arithmetic. A lowercase character is log2(26), about 4.7 bits. An alphanumeric character is log2(62), about 5.95 bits. A character from the printable ASCII set is log2(94), about 6.55 bits. So 15 lowercase characters reach about 70 bits, 12 alphanumeric reach about 71, and 11 from the printable set reach about 72. Fifteen is the single-factor floor, and a 20-character generated password gives roughly 105 bits before you consider the stored hash. Passphrases solve the memorisation problem. The widely used EFF list holds 7,776 short words, which is log2(7776) = 12.9 bits per word. Six words give about 77.5 bits and are usually easier to recall than a random string of equal strength, because they form a sentence-shaped chunk. Four words give about 51.7 bits, fine for a low-value account and not fine for your primary email. The generator here draws from crypto.getRandomValues rather than Math.random, and the strength checker scores an estimate of bits and the guesses that implies.
Managers and passkeys: a setup that holds up
The strongest policy is the one that makes the human's job trivial: the manager generates a unique random password per site, the manager fills it in, and the human never types it. That last part is the security property, not just convenience. A password you type can be captured by a convincing fake login page; a password only the manager will autofill generally cannot, because the manager checks the origin before offering to fill. On master passwords, a passphrase of five or six random words beats a short complex string, and the encrypted vault is what makes many such credentials affordable. Passkeys are the better answer wherever offered. A passkey is an asymmetric key pair held by an authenticator; the site stores a public key, so there is no shared secret to phish, replay, or leak in a breach. Enable them for the accounts that matter first and keep the manager-generated password as the fallback for recovery paths that still need one. Write the recovery codes on paper, and test the restore on a second device before you need it.
Breach checking and a rotation policy that works
Check new passwords against a corpus of known breaches when they are set, not on a schedule. The safe method is the k-anonymity range API: hash the password locally with SHA-1, send only the first five hex characters of that hash as a prefix, and receive every suffix beginning with it. The service sees a prefix shared by thousands of passwords and cannot reconstruct yours; the comparison happens on your machine. This site checks that way, so the full secret never leaves the device. A non-zero hit count means rotate that credential and invalidate any active sessions it protected. For rotation policy, do not rotate on a calendar. Rotate on evidence: a breach notification, a failed-login alert pattern, discovery that a credential was reused, or an offboarding. Avoid secret questions entirely, since their answers are public and recovery is frequently the weakest link. For teams, make sure the login form does not block paste and does not silently trim a pasted passphrase. Those two checks cost nothing and separate a policy people follow from one they route around.
Implementing the checks server-side
A registration handler following the guidance is short. Hash with a memory-hard function such as Argon2id, or PBKDF2-HMAC-SHA-256 with a high iteration count, rather than a bare SHA-256. Reject below the minimum length for your factor. Reject if the whole secret is on your blocklist, and return a message saying it appeared in a breach corpus rather than a generic failure, because a specific reason is what lets a user act. Allow the full 64 characters rather than truncating, since truncating silently makes two different passwords into the same credential. Rate-limit verification attempts both per account and per source, since an unthrottled verifier is a free offline-style attack against your stored hash. Count Unicode code points rather than UTF-16 code units when checking length, or a passphrase with emoji measures double. If you are auditing an older checklist, read the current revision rather than a summary of it, since the 2025 publication moved much of this into normative SHALL and SHOULD language.