Every password-policy post on this site states the same fact in one line: an 8-character floor, 15+ recommended, 64+ supported. That's what NIST SP 800-63B says — see NIST Password Guidelines Explained for the provision itself. This post is the why: what each of those numbers actually buys you, broken down by the specific way an attacker would come after a password, using the exact three attack scenarios this site's own Password Cracking Time Estimator already computes.
The number that matters depends on how you're attacked
"How long until this password is cracked" has no single answer — it depends entirely on the guess rate an attacker can sustain, and that varies by eleven orders of magnitude across three realistic scenarios:
- Online, rate-limited (10 guesses/sec) — an attacker submitting login attempts against a real server that throttles or locks out repeated failures. Slow by construction, regardless of password length.
- Offline, fast hash (~100 billion guesses/sec) — a database leaked with passwords stored as a raw SHA-256 or MD5 hash, or no hash at all, cracked on a single consumer GPU. See Why SHA-256 Should Not Be Used for Passwords for why this scenario exists at all.
- Offline, slow hash (~10,000 guesses/sec) — the same leaked database, but stored with bcrypt or Argon2id at a reasonable cost factor. Six to seven orders of magnitude slower than the fast-hash case, for the same underlying attack.
A password's real strength is never one number — it's three numbers, one per scenario, and the gap between them is enormous.
Length by scenario
The table below runs the site's own crack-time formula — length × log₂(pool size) for entropy, keyspace ÷ 2 ÷ guess rate for time — across common lengths, for a password drawn uniformly from upper- and lowercase letters plus digits (a 62-character pool, the realistic case for most generated passwords).
| Length | Online, rate-limited | Offline, fast hash | Offline, slow hash |
|---|---|---|---|
| 8 | ~3,459 centuries | ~18.2 minutes | ~3.5 centuries |
| 10 | 1.3 × 10⁷ centuries | ~48.6 days | ~13,298 centuries |
| 12 | 5.1 × 10¹⁰ centuries | ~5.1 centuries | 5.1 × 10⁷ centuries |
| 14 | 2.0 × 10¹⁴ centuries | ~19,649 centuries | 2.0 × 10¹¹ centuries |
| 16 | 7.6 × 10¹⁷ centuries | 7.6 × 10⁷ centuries | 7.6 × 10¹⁴ centuries |
Read the middle column first — it's the one that moves. At 8 characters, an offline fast-hash attack is finished in about 18 minutes; at 12, that same attack takes centuries; at 16, it's not realistic at any budget. The online and slow-hash columns barely matter for this comparison — they're already effectively unbreakable at 8 characters, because rate-limiting and a deliberately slow hash are each independently doing most of the work. Length is the variable that has to compensate when one of those other layers isn't there.
Why NIST's 8-character floor isn't a security target
The 8-character SHALL is a floor for subscriber-chosen secrets, published alongside two other SHALLs in the same document: rate-limit every online attempt, and salt-and-hash every stored secret with a suitable one-way function. NIST isn't claiming 8 characters alone is secure — it's assuming those other controls hold, the way the table above shows they need to. The floor is a minimum for a system that already has rate limiting and proper hashing, not a substitute for either one. A site that ever gets its storage wrong — a fast hash, a missing salt, a config mistake — has no fallback once that assumption breaks, and 8 characters buys minutes, not centuries. See Password Hashing Best Practices and Understanding Salt and Pepper for what "proper hashing" actually requires.
Practical recommendations by account type
- Low-value or throwaway (a forum you'll use once, a trial signup) — 12 characters, generated, is already well past the point where length is the limiting factor for any realistic attacker.
- Everyday accounts (most SaaS logins, retail, social) — 16 characters, generated by a password manager, covers every scenario in the table above with room to spare, and costs nothing extra to type since you're not the one typing it.
- High-value (primary email, banking, your password manager's own master password, anything with admin or root access) — 20+ characters or a long multi-word passphrase. These are the accounts where the eventual compromise of one upstream service's hashing practices is most likely to matter, and where the practical cost of extra length is smallest — a password manager or a memorized passphrase carries it the same either way.
- Machine-generated credentials (API keys, service-account secrets) — length here is usually dictated by the issuing system rather than a personal choice, and the real lever is rotation, not length — see Password Rotation: Good or Bad? for the one case where scheduled rotation genuinely makes sense.
Length beats variety, past a point
Adding a symbol requirement to an 8-character password raises the pool from 62 to 95 characters — entropy goes up by about 5 bits. Adding four more characters to that same password, keeping the same 62-character pool, adds roughly 24 bits. Once a password draws from more than one or two character classes, length is doing almost all of the remaining work; a longer password from a smaller alphabet consistently beats a shorter one stuffed with symbols. Password Entropy Calculator shows this directly on any password you check — length and pool size both feed into one entropy number, and it's easy to see which one moved it more.
FAQ
Does NIST's 8-character floor mean 8 characters is secure?
Only conditionally — see the table above. It's secure against online guessing and against a properly slow-hashed offline attack, and it fails quickly against a fast-hash offline attack. The floor assumes the other NIST SHALLs (rate limiting, proper hashing) are also in place; it was never meant to stand alone.
Is 64 characters overkill for a normal account?
For most accounts, yes — it's a ceiling NIST requires systems to support, not a target you need to hit. 16–20 characters already covers every scenario in the table above with enormous margin. 64 exists mainly so a password manager's generated string or a long passphrase never hits an arbitrary wall.
Should a policy require symbols so people hit these lengths faster?
No — composition requirements are a NIST SHALL NOT, and What Makes a Strong Password Policy? covers why they backfire in practice (predictable substitutions, not real randomness). The fix for a short password is more length, generated randomly — not more character classes packed into the same short string.
What about passphrases made of multiple words?
Same underlying math, a different alphabet — each word drawn from a wordlist functions like one "character" from a much larger pool, so a handful of random words can reach the same entropy as a long random string while staying easier to memorize. Check any passphrase's actual entropy the same way as a character-based password in Password Entropy Calculator.
Try it yourself
Password Cracking Time Estimator runs this exact table for any length and character set you choose, not just the rows above. Password Entropy Calculator checks a real password you already have, and Password Generator creates a new one at whatever length you land on. To set a length requirement organization-wide, Password Policy Generator turns it into a policy checked live against NIST SP 800-63B.