How Password Research Changed NIST's Guidance

Rules such as “eight characters, one uppercase letter, one digit, one symbol, and a mandatory change every 90 days” came from an understandable attempt to make guessing more expensive and shorten the useful life of a stolen secret. The problem was not the arithmetic itself but human behavior. People do not select characters uniformly or invent an entirely new password on schedule, so a formally complex policy often creates patterns that attackers already know.

NIST's guidance did not change because of one sudden discovery. By 2017, research on real breach data, laboratory studies, and observations of password changes had accumulated, and SP 800-63B brought those findings into a more practical security model. The final 2025 revision continued that direction and turned several earlier recommendations into requirements.

Why composition rules delivered less than promised

When a password comes from a uniform generator, expanding its alphabet really does increase the search space. It is easy to turn this true statement into a false assumption that requiring one uppercase letter, digit, and symbol makes a person use the full space with equal probability. In practice, many users capitalize the first letter, place a digit near the end, and choose ! as the symbol.

The study Of Passwords and People compared composition policies not only by their written requirements but also by the passwords people produced, their memorability, and their usability cost. Other work attacked large collections of disclosed passwords and found that conventional policy metrics represented real guess ordering poorly. NIST now summarizes the result directly: composition rules provide less benefit than initially expected and have a severe effect on usability and memorability.

The illustrative password Password1! satisfies several character categories, but almost all of its structure is predictable. An attacker does not need to begin with an exhaustive search across every printable character. Common words, names, keyboard sequences, and familiar transformations come first. A useful defense must therefore consider not only the size of the permitted alphabet but the probability with which people choose particular values.

Why scheduled rotation also lost its default status

Regular changes had a rational goal. If an attacker quietly obtained a working password, expiration would limit how long it remained useful. That measure only helps under a particular threat model, while every user pays its cost at every rotation. People often preserve the base and change a month, season, number, or final symbol because continually memorizing unrelated secrets is difficult.

The 2010 study The Security of Modern Password Expiration examined password histories for more than 7,700 accounts and generated guesses for a new password from its predecessor. It found that consecutive values were often connected by predictable transformations, making an old password valuable when searching for the new one. Later user studies refined the picture and did not confirm every feared side effect, but they likewise found no persuasive universal security gain from mandatory rotation.

This does not imply that a password should never be changed. It should be replaced after a leaked hash database, phishing incident, infected device, discovery of password reuse, or other evidence of compromise. NIST moved away specifically from calendar-driven changes without such a signal because they impose recurring work without tying it to a real risk event.

What the 2017 edition actually said

The first final NIST SP 800-63B appeared in 2017 and addressed remote authentication in digital identity systems. That scope matters. The publication defines requirements for the US federal context and serves as an influential industry reference, but it is not a universal law for every website.

For a user-chosen memorized secret, the 2017 edition set a minimum of eight characters and recommended allowing at least 64, including spaces and Unicode. A new or changed value had to be checked against a list of common, expected, and compromised choices. The service also had to limit failed attempts and store the password as a salted hash designed to resist offline attacks, with an adjustable computational cost.

Composition rules and arbitrary periodic changes received SHOULD NOT, a strong recommendation against using them without a compelling reason. The document also recommended allowing paste so that sites would not obstruct password managers. The 2017 approach therefore did more than replace “complexity” with length. It moved attention to the entire defense path, including screening obvious choices, rate limiting, secure storage, and support for unique passwords.

What the 2025 revision strengthened

NIST published the final SP 800-63B-4 in July 2025. A password used as the only authentication factor must now contain at least 15 characters. When it is used only within a multi-factor process, a service may permit a shorter value but no fewer than eight characters. This allowance concerns a centrally verified password within MFA; local device PINs and other activation secrets have a separate section.

The prohibitions on additional composition rules and scheduled password changes now use the normative SHALL NOT. A change is required when there is evidence of compromise. A service must compare the entire prospective password against a blocklist of common, expected, or previously exposed values, reject a match, and explain why. The standard does not require rejecting every dictionary word that happens to appear as a substring.

The 2025 revision also requires support for password managers and autofill, recommends permitting paste, and suggests an option to display the password during entry. Services should allow a maximum length of at least 64 characters, should accept printable ASCII and spaces, and should support Unicode with normalization. NIST also states explicitly that an ordinary password is not phishing-resistant, regardless of how long it is.

A blocklist does not have to send a password to an external service. It can be checked locally. Another option is Pwned Passwords, where the client hashes the password, sends only the first five characters of its SHA-1 hash, and compares the full suffix locally. This answers whether the value appears in a known corpus, but a missing match does not prove that the password is strong.

Where entropy is useful and where it misleads

For a generator that independently and uniformly selects each of L characters from a pool of N, the search space contains N^L possible strings and the entropy is L × log₂(N). Twelve random lowercase Latin letters provide about 56.4 bits, while eight random characters from 95 printable ASCII symbols provide about 52.6. Within this precisely defined model, additional length can contribute more than several extra character categories.

A password seen in isolation does not carry a reliably measurable amount of “entropy.” Entropy describes the generation process and its probability distribution as known by an attacker. Human choices contain dependent words and symbols, common patterns receive enormous priority, and dictionaries are tried before random enumeration. Universal thresholds such as “80 bits is enough for every case” also conceal the difference between an online login protected by rate limiting and offline guessing against a stolen hash.

Even for a generator, the simple formula may only be an upper bound. Requiring every selected category, forbidding duplicates, fixing the first character, or inserting a user-supplied word changes the distribution. Strength cannot be converted into a cracking time without further assumptions either; speed depends on the storage algorithm, its parameters, the attacker's hardware, and whether guesses can be submitted through the service itself.

What Password Generator does

Password Generator draws the random portion from crypto.getRandomValues and uses rejection sampling to avoid modulo bias. Length is adjustable from 4 to 128 characters, while the pool can include uppercase and lowercase Latin letters, digits, and symbols. It can remove similar characters, prohibit duplicates, include or exclude specific characters, and require a selected category in the first position.

The meter displays the upper-bound estimate log₂(pool size) × random positions. The tool correctly excludes a fixed inserted word from the random count and warns when too few generated characters remain. Requiring all selected categories, prohibiting repetition, and fixing the beginning still narrow the exact distribution, so the number should be treated as a guide rather than a certificate of strength.

The generator can create a batch of five values and offers three memory views for the current password: four-character chunks, a phonetic reading, and a word sequence for constructing a story. None of these aids is stored, but a password manager remains the better home for a random unique password. All code runs locally in the browser; the value is not transmitted, logged, saved, or checked against breach data.

That final distinction is important. The tool generates a secret but does not implement the complete NIST policy. It permits lengths below the relevant minimum, does not know whether an account uses single-factor authentication or MFA, and contains no blocklist. For an individual account, a practical workflow is to choose a generous length accepted by the service, store a unique result in a manager, and enable phishing-resistant MFA when the service offers it.

Related tools

Password GeneratorGenerate strong passwords with a cryptographically secure generator, adjustable character sets, an entropy strength meter, and batch output.Passphrase GeneratorGenerate passphrases from the official 7,776-word EFF long list with adjustable word count, separator and capitalization, plus an entropy meter.Key Pair GeneratorGenerate Ed25519 or RSA (2048/4096) key pairs with the Web Crypto API — OpenSSH public key, PEM private key, SHA256 fingerprint, and downloadable files, all client-side.