Password Strength in 2026: What Length and Character Sets Actually Buy You

Password advice has a reputation for being simultaneously obvious and wrong. “Use a capital letter, a number, and a symbol” is advice that produced a generation of P@ssw0rd1 passwords — technically compliant, practically useless. NIST’s current guidance looks nothing like that, GPU cracking has continued to advance, and passkeys are real now — but not ubiquitous. Let’s look at where things actually stand.

What entropy means, concretely

Entropy is a measure of unpredictability, expressed in bits. For passwords generated from a known character set at a known length, the formula is simple:

entropy = log2(charset_size ^ length)
       = length × log2(charset_size)

A few common cases:

Character set	Size	12 chars	16 chars	20 chars
Lowercase only (a-z)	26	56 bits	75 bits	94 bits
Alphanumeric (a-z, A-Z, 0-9)	62	71 bits	95 bits	119 bits
Full printable ASCII	95	78 bits	104 bits	131 bits

For Diceware passphrases, each word contributes about 12.9 bits (log2(7776)). A 6-word passphrase like correct-horse-battery-staple-river-desk has roughly 77 bits of entropy — comparable to a random 13-character alphanumeric password, and considerably more memorable.

The important caveat: this math assumes the password is generated with a cryptographically secure random number generator (CSPRNG). If a human chooses the password, the effective entropy is much lower than the theoretical maximum — human brains are terrible at choosing randomly.

What NIST SP 800-63B-4 actually says

NIST’s digital identity guidelines, currently in their fourth revision, made a substantial shift from earlier thinking. The headline changes:

Length over complexity. The guidance recommends supporting passwords up to at least 64 characters and using minimum length (8 characters for user-chosen, more for generated) as the primary metric. Mandatory complexity rules — “must include a symbol” — are explicitly discouraged.

No forced rotation. Periodic password expiration (the old “change your password every 90 days” policy) is no longer recommended unless there’s evidence of compromise. Forced rotation leads to predictable patterns: Password1, Password2, Password3.

Check against known breaches. New passwords should be checked against databases of known compromised passwords (like the Have I Been Pwned dataset). A technically complex password that appeared in the 2022 RockYou2021 breach is worthless regardless of its entropy score.

No hints or knowledge-based authentication. “Your mother’s maiden name” is not authentication; it’s an answer that can be researched or guessed.

The 800-63B-4 rationale is worth reading directly if you’re implementing password policies. The short version: complexity rules optimize for passing a policy check, not for actual security.

GPU cracking in 2026

Understanding what attackers can do with modern hardware matters for calibrating recommendations. Consumer GPU cracking hardware — specifically the kind that uses RTX 4090s or AMD RX 7900 XTX cards — can attempt:

• MD5: ~200 billion hashes per second per card
• bcrypt (cost=10): ~25,000 hashes per second per card
• Argon2id (typical config): ~2,000 hashes per second per card

This is why the hash algorithm used for storage matters as much as the password length. MD5 is not a password hashing function; SHA-256 and SHA-512 are not password hashing functions. bcrypt, scrypt, and Argon2id are designed for password hashing — they are computationally expensive by design.

An attacker’s ability to crack a password depends on:

1. Whether they have the hash (requires breaching the service)
2. Which algorithm was used to generate it
3. Whether the password appears in a wordlist or follows a predictable pattern

A rough estimate of crack time for a random password, assuming Argon2id and a well-funded attacker with a rack of GPUs (say, 1 billion attempts per second across their fleet):

Entropy	Approximate crack time
40 bits	Under a day
60 bits	~36 years
80 bits	~38 million years
100 bits	~40 trillion years

At 80 bits of entropy, you’re well past the threshold where direct brute force is not a realistic attack. The realistic threats are phishing, credential stuffing (reused passwords), keyloggers, and social engineering — none of which entropy defeats on its own.

This is why password uniqueness matters as much as password strength. A 90-bit password that you’ve used on 12 sites is weak against credential stuffing even though its entropy is high.

Why forced complexity rules backfire

The problem with “must include uppercase, lowercase, number, and symbol” is that it constrains the search space in ways that are predictable to attackers.

People respond to character requirements systematically: capital at the start, number at the end, symbol before the number. Password1! is the canonical example, but the pattern generalizes. Dictionary attacks against policies with known rules (a.k.a. “rule-based cracking” in hashcat’s terminology) can test billions of rule-applied variations efficiently.

A completely random 12-character password from a 95-character printable ASCII set has ~78 bits of entropy and is indifferent to complexity rules — because it was generated randomly, not chosen. The complexity requirement adds nothing to a randomly-generated password; it only matters (negatively) when humans choose passwords.

If your system enforces complexity, you’re adding friction for randomly-generated passwords (users can’t use their manager’s output because it doesn’t meet your rules) while not meaningfully raising the bar against attackers who run rules anyway.

Passkeys: real, but not everywhere

Passkeys (FIDO2/WebAuthn credentials) replace passwords entirely with a public/private key pair. Authentication happens via device biometric or PIN — the private key never leaves the device. Phishing is structurally impossible because the credential is scoped to the exact origin.

As of 2026, passkeys are well-supported for consumer use: Apple, Google, and Microsoft accounts all support them. Major sites like GitHub, 1Password, PayPal, and Best Buy have passkey login. Browser support is solid across Safari, Chrome, and Firefox.

Where passkeys are not yet the answer:

Shared infrastructure. A server with multiple admin accounts, a shared root login, a VPN credential — these don’t map cleanly to a passkey flow because passkeys are per-device and tied to a person, not a shared role.

Command-line contexts. SSH keys are conceptually similar to passkeys but predate the FIDO2 ecosystem. The tooling for using FIDO2 hardware security keys with SSH exists but is not universally deployed.

Legacy systems. Anything that requires a password to be typed into a physical terminal, a form that doesn’t support WebAuthn, or a vendor portal built in 2008.

For most consumer accounts where passkeys are supported, using them is strictly better than any password. For everything else, the password hygiene advice below still applies.

Practical advice, without the moralizing

Generate, don’t invent. Human-chosen passwords are predictable. Use a CSPRNG. Our Password Generator runs entirely in the browser — the generated passwords are never transmitted anywhere.

Use a password manager. Bitwarden, 1Password, KeePassXC — pick one and actually use it. The manager generates random passwords and handles retrieval. You remember one strong master passphrase; it remembers the rest. This solves reuse, which is a bigger practical threat than password strength at this point.

Aim for 16+ characters for critical accounts. At 16 random characters from a 95-character set, you have ~104 bits of entropy. That’s not crackable in any realistic timeline regardless of what happens to GPU performance over the next decade.

For memorable passphrases: 6+ Diceware words. Six words from the EFF Diceware wordlist gives ~77 bits of entropy. This is appropriate for things you need to type, like a password manager master password or a disk encryption passphrase. Try our Random String Generator for raw random output you can incorporate into a passphrase.

Check your existing passwords. Our Password Strength Checker estimates entropy and flags patterns. If you find passwords under 60 bits, they’re worth rotating — especially for accounts that don’t yet support passkeys.

Never reuse passwords across services. The threat isn’t that someone cracks your specific password hash. The threat is that a service you used in 2019 had a breach, the hash was cracked, and the credential was sold in bulk. Unique passwords per service contain the blast radius to one account.

What to stop doing

• Rotating passwords on a fixed schedule without evidence of compromise
• Adding a ! to the end to meet a symbol requirement
• Using the same base word with incrementing numbers across sites
• Treating a memorable password as “secure enough to reuse” — even a strong one

The security model has shifted. The question is no longer primarily “is this password hard to brute-force?” It’s “is this password unique, generated, and stored in a manager?” Those properties are more protective against the actual attack landscape — credential stuffing, phishing, and large-scale breach exploitation — than raw entropy alone.

Entropy still matters. A 6-character password is weak regardless of how it’s stored. But entropy is a floor, not a ceiling, and the ceiling is lower than it looks once human behavior enters the picture.