Should I require uppercase, numbers, and symbols in passwords?

No. NIST SP 800-63B explicitly states that verifiers should not impose composition rules on memorized secrets. Forced composition rules (must include uppercase, number, symbol) encourage predictable patterns like Password1! rather than genuinely strong passwords. A long passphrase (correct horse battery staple) is stronger than a complex short password and easier to remember.

Last verified April 2026 · 6 min read

Password strength UI done right: NIST 800-63B for product teams

Q: What does NIST 800-63B say about passwords?

NIST SP 800-63B (Section 5.1.1.2) explicitly recommends: minimum 8 characters, allow up to 64. No forced composition rules (no required uppercase/lowercase/number/symbol mix). No forced rotation on a schedule - only rotate on evidence of compromise. Check against known-breached password lists. Allow paste. Show password visibility toggle. No password hints.

Q: How do I check passwords against breached lists?

Use the HaveIBeenPwned Pwned Passwords API with k-anonymity. Send the first 5 characters of the password's SHA-1 hash to the API; receive back a list of matching hashes and breach counts. This means you never send the full password to a third party. The API is free, privacy-preserving, and covers 12+ billion breached passwords as of 2026.

"Memorized secrets SHALL be at least 8 characters in length... Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) on memorized secrets."
NIST SP 800-63B, Section 5.1.1.2

The single most ignored government-grade research in consumer web signup UX. NIST SP 800-63B was originally written for US federal systems but is cited by security professionals as the standard for all digital identity contexts. Its password guidance is unambiguous, evidence-based, and contrary to what most signup forms still do.

Most products still enforce composition rules that NIST explicitly deprecated. They do so because the legacy rule felt right in 2005, before research showed that complexity rules create predictable patterns rather than strong passwords.

The NIST rules: right and wrong

Minimum length: 8 characters

Should-allow up to 64. Longer is better.

No forced composition rules

No must-have uppercase/lowercase/number/symbol mix.

No forced rotation on a schedule

Only rotate on evidence of compromise.

Check against breached-password lists

HIBP Pwned Passwords API, free, k-anonymity model.

Allow paste

Blocking paste breaks password managers.

Show password (visibility toggle)

Eye icon. Standard in 2026.

No password hints

Hints are an attack surface, not an aid.

Forced uppercase + number + symbol

Explicitly deprecated by NIST 800-63B.

90-day rotation policy

Encourages predictable patterns (Password1! -> Password2!).

Maximum length under 64 characters

Penalises passphrases and password managers.

Disable paste on password fields

Breaks password managers. Never do this.

The breached-password check

NIST recommends checking new passwords against known-compromised lists at signup and password-change time. The best implementation is the HaveIBeenPwned Pwned Passwords API with k-anonymity. The k-anonymity model works: you send the first 5 characters of the password's SHA-1 hash to the API. The API returns all hash suffixes that match those 5 characters. You check client-side whether your full hash is in the returned list. The HIBP server never receives your password or the full hash.

As of 2026, the HIBP database contains over 12 billion breached passwords. A user choosing "password123" will get an immediate warning that this password has appeared in data breaches 3.5 million times. This is better security communication than a composition rule, and it does not penalise users who choose genuinely strong passphrases.

Strength meter UX

If you show a password strength meter, use zxcvbn (Dropbox's open-source strength estimator) rather than a simple character-count meter. zxcvbn uses entropy estimation and common-pattern detection to give a score from 0-4. A simple red/yellow/green meter based on length is misleading - "Aaaaaa1!" meets most composition rules but is weak by entropy. zxcvbn scores it correctly as weak.

Never force a minimum zxcvbn score at signup. Show the meter as guidance and let users decide. The NIST principle is minimum-length enforcement, not strength-gate enforcement.

Password managers and visibility toggle

Do not disable autocomplete on password fields. Do not disable paste. The user's password manager is their security tool; breaking it for your product is both a conversion problem and a security-culture problem. Websites that disable paste on password fields typically do so based on a mistaken security intuition from 2010.

The visibility toggle (eye icon) is standard in 2026. Luke Wroblewski's research from 2009 established that visibility toggles reduce password-entry errors. The confirm-password field is the legacy alternative; replace it with the toggle.

Frequently asked questions

What does NIST 800-63B say about passwords?+

Minimum 8 characters, allow up to 64. No forced composition rules. No forced rotation. Check against breached lists. Allow paste. Show visibility toggle. No hints. Available free at pages.nist.gov/800-63-3/sp800-63b.html

Should I require uppercase, numbers, and symbols?+

No. NIST explicitly deprecated composition rules. They encourage predictable patterns (Password1!) rather than strong passwords. A long passphrase is stronger and easier to remember.

How do I check passwords against breached lists?+

HaveIBeenPwned Pwned Passwords API with k-anonymity. Send first 5 chars of the SHA-1 hash. Never send the full password. Free, privacy-preserving, covers 12+ billion breached passwords.