English

Text & everyday tools · Password Generator

Complexity rules vs length: what NIST 800-63B changed about passwords

· Why it matters

passwords policy security

A policy document pointing to verified length and character controls
Original ToolAcre vector illustration

Summarises the shift in NIST's digital identity guidelines — away from composition rules and forced rotation, toward length, breach-list screening and usability — and what it means for how you generate passwords.

The policy that produced Summer2024! — how composition rules and ninety-day resets shaped predictable passwords

The workbook begins with a historical explanation for predictable seasonal passwords, but no policy archive, survey or standards text is included among the repository sources for this assignment. Repeating that account from memory would create an unsourced authority claim. The correction is to start with what ToolAcre can prove: the settings it accepts and the generation behavior behind them.

A generator cannot decide an organisation’s password policy. It does not know account value, recovery controls, authentication architecture or regulatory context. The person writing policy must use current approved sources. ToolAcre can then generate a value that matches explicit field constraints, without representing those controls as universal best practice.

The repository does not document the history or authority of external password policies

No copy of NIST SP 800-63B is cited by the password product, so this article does not summarize its composition, rotation or breached-list provisions. The verified local controls are three to sixteen passphrase words, word lengths from one to twenty, several case and delimiter modes, and character-password lengths from eight to 128 with selectable classes.

The manifest also states what the product does not do: no account, no storage, no history, no breach checking and no manager features. Those boundaries matter when translating a policy. A requirement to screen existing credentials or govern recovery cannot be satisfied by selecting another generator option.

ToolAcre’s verified controls, not a paraphrase of NIST SP 800-63B

Explanations for why external guidance changed require primary documents and supporting research. Neither is supplied here, so the article leaves that history out rather than inventing evidence. A title in the content plan is a brief, not a citation, and the authoring contract explicitly requires correction when an outline exceeds source truth.

The practical result is a cleaner division of labor. Policy owners cite and approve their authority. ToolAcre exposes deterministic controls and a cryptographic random path. Readers can verify whether the output mechanism meets the stated local rule, but should not infer that the local rule is endorsed by the generator.

Why policy-history claims are omitted without a cited standards source

More independent draws expand a known generator choice space. For a passphrase, each additional word adds log₂ of the actual eligible word count. For a character password, each extra position draws from the selected alphabet after required classes have been represented. That arithmetic describes settings, not a universal minimum or guaranteed outcome.

Length can also collide with destination limits, byte handling or unsupported characters. A policy should state which system boundary applies and whether the measure is characters or something else. ToolAcre does not test another service’s field, so a successful local generation is not proof that the destination will accept or preserve the entire value.

What generated length buys inside a known choice process

A usable organisational policy should be written from approved security and compliance sources, name account classes and explain exceptions through the organisation’s own governance. The generator should appear only as an approved way to produce fresh candidates that match those requirements. It should not be cited as the reason the requirements exist.

ToolAcre also must not be conflated with a password manager. It creates one current value and forgets it when replaced or the page is left. Storage, distribution, emergency access, rotation events and account recovery require separate managed processes. Do not send or reuse a generated credential merely because its settings matched a policy paragraph.

Write local policy from approved sources; use this tool only for generation

Suppose an approved local field rule requires lowercase, uppercase, digits and symbols and accepts twenty characters. Enable the four character classes and keep length twenty. The engine first draws one character from each class, fills the remaining positions from their union and securely shuffles the result, so the composition requirement is satisfied without a predictable class prefix.

If the local rule instead accepts multiword credentials, select a permitted delimiter and word count within the interface bounds. Record the settings, not the generated value, in policy documentation or screenshots. A credential placed in an example becomes public and should never be used for an account.

Worked example: translate a local character rule into supported generator settings

Multifactor requirements, federation, identity proofing and standards conformance are outside the generator source. So are legal interpretations and sector-specific mandates. This article intentionally omits them because no primary authority has been verified here, not because they are unimportant.

The same boundary applies to breached-password checks. ToolAcre does not accept an existing password or send it to a checking service. If an approved policy requires screening, use an approved system designed for that function and review its privacy model separately.

Standards, federation and authentication requirements remain outside repository evidence

Treat Password Generator as an implementation component beneath policy, not a policy author. Its controls and failure paths are inspectable: supported bounds, explicit classes, EFF word assets, Web Crypto, rejection sampling, no weak fallback and no persistence. Those are product facts.

Obtain normative requirements from the current primary source your organisation accepts, then map them to these product facts. That approach avoids citing standards from memory and prevents a convenient browser tool from being mistaken for universal password-policy law.