Review a password candidate without false assurance

Problem

Password reviews commonly fail in two opposite ways. A simplistic meter rewards uppercase letters, digits, and symbols, so a decorated common password appears strong. A more capable pattern model avoids that error but can create a different false confidence when its top score is treated as proof of safety. No client-side estimate knows every leaked password, personal fact, language-specific word, attacker dictionary, verifier hash cost, online rate limit, recovery path, phishing route, browser extension, or reused account. Testing also creates exposure if a real credential is pasted into a page, copied into a screenshot, sent to telemetry, or included in a support ticket. NIST SP 800-63B-4 makes the separation clear: verifiers need length rules, a blocklist of common or compromised values, support for password managers and paste, rate limiting, protected channels, and suitable salted hashing; they should not rely on composition rules or arbitrary periodic changes. A useful review therefore needs a defined question, a non-secret test boundary, a trusted local environment, full-value analysis, conservative interpretation, separate breach and account-control checks, and a decision record that contains no password. This procedure cannot turn a password into phishing-resistant authentication, so MFA or a passkey remains part of the final account decision.

Sources and standards

These authoritative references define the formats or security boundaries used in this workflow. Tool-specific verification is documented separately above.

• NIST SP 800-63B-4: Authentication and Authenticator Management

  National Institute of Standards and Technology

When to use this

• A newly generated password or passphrase needs a quick pattern review before it is submitted to a service.
• A product team is evaluating password-meter feedback without exposing customer credentials or adopting character-composition scoring.
• Security training needs synthetic examples that demonstrate common words, dates, repeats, sequences, and keyboard patterns.
• A support case claims that a candidate was rejected or over-scored and can be reproduced with a clearly synthetic value.
• An organization is documenting how client-side feedback relates to its separate blocklist, rate-limit, MFA, recovery, and password-storage controls.

Steps

1. Step 1

   Define the decision and the limits of the review

   State whether the task is to reject a new candidate, test a user-interface message, or verify a service policy. Do not describe the goal as proving that a password is secure. Record the account class, whether the password is a single factor or part of MFA, the destination's supported length, and who owns the final decision without recording any secret.

2. Step 2

   Use a new or synthetic candidate

   Prefer a value that has not yet become a credential. For training, support, screenshots, and automated tests, use an obvious synthetic example that will never be assigned to an account. Existing banking, administrator, email, recovery, or password-manager master credentials should be reviewed with the trusted manager or destination service rather than pasted into another page.

3. Step 3

   Prepare a controlled browser session

   Use an updated device you control, verify the origin, close screen sharing and recording, and consider the permissions of installed browser extensions. Keep the field masked unless visual verification is necessary. Avoid clipboard history, shared devices, remote support sessions, and screenshots containing the value.

4. Step 4

   Analyze the complete value without normalizing it

   Enter the exact candidate, including intended spaces and Unicode, and run the local analysis. Do not trim, change case, substitute symbols, or silently shorten it before the check. If the destination applies normalization or a lower maximum, test that behavior separately because the checker evaluates the value it receives, not the service's transformed value.

5. Step 5

   Interpret patterns before the headline score

   Review common-password, dictionary, keyboard, repeat, sequence, and date findings first. Treat the 0-to-4 score and 10^n guess scale as rough output from one model, not a universal crack time. A low result is sufficient reason to reject the candidate; a high result is only provisional because unknown personal, language-specific, or breached values may be missed.

6. Step 6

   Run the controls the meter cannot perform

   Confirm the service accepts the complete value and applies the appropriate NIST length rule, server-side common or compromised-password blocklist, protected transport, salted password hashing, and rate limiting. Check uniqueness in the password manager, use the destination's breach monitoring where available, enable MFA or a passkey, and review recovery and session-revocation paths. Never send the raw password to an unapproved breach API.

7. Step 7

   Decide, clean up, and retain non-secret evidence

   Reject and regenerate when a weak pattern appears, accept only provisionally when the estimate is favorable and every separate control is satisfied, or escalate when the destination policy is unclear. Clear the field and temporary clipboard or screenshots. Record only the tool version, model result category, length checkpoint, pattern categories, destination policy result, MFA state, decision, reviewer, and timestamp.

Example

Synthetic candidate: a published common word followed by a predictable year and symbol; single-factor service requires 15-64 characters

Decision: reject and regenerate; evidence records low pattern estimate, common-word finding, length result, and no raw candidate

Common mistakes

FAQ