The Science of Password Strength: Why Length Beats Complexity

For twenty years, corporate IT departments have demanded the same thing: at least eight characters, one uppercase, one number, one symbol, change every ninety days. The result is a generation of users who write "Summer2024!" on a sticky note and then update it to "Summer2025!" when the rotation forces them. This is not a rant about users being lazy. It is a rant about a policy that was wrong from the start.

The math behind password strength has been well-understood for decades. Length matters more than character classes. Rotation without cause makes things worse. The only passwords strong enough against modern attackers are the ones humans do not memorize at all. This guide walks through the reasoning, the math, and the practical implications — and shows you how to generate and test passwords locally without sending them to a server.

Entropy: the only unit that matters

Entropy is the measure of how unpredictable a password is, measured in bits. One bit of entropy means one binary guess. Fifty bits of entropy means 2^50 possible passwords, which is about a quadrillion. The number you want for something important is at least 80 bits; for a master password on a password manager, shoot for 100+.

Here is the key point: entropy is a property of how the password was generated, not of what the password looks like. A six-character password chosen randomly from a 94-character set has log2(94^6) ≈ 39 bits of entropy. A 20-character password where the user typed "correcthorsebatterystaple" has much more entropy if chosen at random from a word list — but zero entropy if the user read it off the famous XKCD comic, because the attacker has that comic too.

This is why the concept of "password strength" in the UI is always a lie in one direction. The little red/yellow/green bar looks at character classes and length, not at the generation process. A password like "Password123!" has about 48 bits by naive counting and roughly 0 bits in reality, because it is in every breach dictionary. Real entropy requires real randomness.

Why length beats complexity

Each additional character in a random password adds log2(alphabet size) bits of entropy. For a random 94-character alphabet, that is about 6.55 bits per character. Adding symbols and mixed case to an 8-character password bumps you from log2(26^8) ≈ 37.6 bits to log2(94^8) ≈ 52.4 bits — a gain of about 15 bits. Adding 3 more lowercase characters to the original? log2(26^11) ≈ 51.7 bits — nearly the same.

The math is mathematically simple but psychologically counterintuitive. Humans feel like "P@ssw0rd!" is more secure than "correcthorsebatterystaple" because it looks more complicated. An attacker's dictionary disagrees. The long phrase has more entropy, is easier to memorize, and is harder to crack — if it was generated randomly, not copied from a comic.

Test this yourself with Password Strength Checker. Enter a typical "complex" 8-character password and look at the estimated crack time. Now enter a random 16-character lowercase password. The second one crushes the first by many orders of magnitude, and it is actually memorable.

Dictionary attacks and the real threat model

A brute-force attack tries every possible character combination. For anything over 10 characters, this is currently impractical. A dictionary attack tries lists of known or likely passwords — and this is what attackers actually use, because the math is dramatically cheaper.

The dictionaries attackers use include:

• The RockYou leak (14 million unique passwords from a 2009 breach, still in use).
• Aggregated leaks from major breaches — Have I Been Pwned's dataset contains hundreds of millions.
• Rule-based mutations of common words: "password" → "Password" → "P@ssword" → "P@ssword1" → "P@ssword2024!".
• Common passphrase templates: names + years, sports teams + numbers, lyrics.

Your password is safe against a dictionary attack only if it is not in any of these lists and could not be produced by any plausible rule applied to a word in these lists. The only reliable way to achieve that is to generate with true randomness — which no human can do reliably in their head.

Use Password Generator for high-entropy random passwords. It uses the browser's crypto.getRandomValues() API, which produces cryptographically secure random bytes locally. The password can be processed without a FastTool upload workflow, never touches a server log. You generate, copy into a password manager, and move on.

Why the server's KDF matters as much as your password

Here is the overlooked half of the equation: the attacker usually does not see your plaintext password. They see the hash stored in a database they breached. How fast they can test candidate passwords against that hash depends entirely on the key derivation function the server used.

Fast hashes: the nightmare scenario

If the server stored passwords with SHA-256 (as in, just raw SHA-256, with or without salt), an attacker with a modern GPU can test tens of billions of candidates per second. Your 12-character random password is broken in hours. This happens. Many legacy systems still store passwords this way.

Slow hashes: the right approach

Modern password hashing uses a deliberately slow KDF: bcrypt, scrypt, Argon2id, or PBKDF2 with a high iteration count. The slowness is the feature. Bcrypt at cost 12 takes about 250ms per hash on a modern CPU. That is invisible during login but devastating to a brute-forcer — the same GPU that tested billions of SHA-256 candidates per second now tests only a few thousand bcrypt candidates per second. Your 12-character password is now safe for decades.

If you run a system that stores passwords, use Bcrypt Generator locally to experiment with cost parameters. Start at 12 and increase until the hash takes ~250ms on your production hardware. For new systems, Argon2id is the preferred choice per the RFC 9106 specification. For integrity hashing (non-password data), Hash Generator handles SHA-256 and friends for verification workflows.

What NIST actually says now

NIST SP 800-63B is the authoritative guidance for US federal agencies on digital identity, and most of the rest of the industry follows it. The 2017 revision (reaffirmed in later drafts) flipped several conventional wisdoms on their head:

• Stop forced rotation. Do not require users to change passwords on a schedule without a reason. Forced rotation leads to predictable increments and is net-negative for security.
• Stop composition rules. Do not require specific character classes. Check the password against a breach corpus and a dictionary of common passwords instead.
• Minimum 8 characters, allow up to 64. Do not set a maximum that is too low. Allow spaces and all Unicode.
• Do not store password hints. Do not use security questions as a primary recovery mechanism.
• Rate-limit login attempts. This is as important as the password itself.

The OWASP Authentication Cheat Sheet aligns with this guidance and adds practical implementation notes — use it as your working reference when specifying password requirements for a new system.

A practical policy you can actually follow

Forget about remembering passwords. That is the one insight that makes everything else work. Use a password manager (1Password, Bitwarden, KeePass). Let it generate and store high-entropy passwords for every site. Memorize one strong master password and nothing else.

For the master password itself, where you do need to remember it: generate a passphrase of five or six random words from a good wordlist (the EFF Diceware list is the standard reference). Five words from a 7,776-word list gives about 65 bits of entropy, which is enough to resist offline brute force of a good KDF. Six words gives 77 bits, which is comfortable.

Layer on multi-factor authentication everywhere you can. A passkey or hardware key is ideal; a TOTP app is acceptable; SMS is better than nothing but has well-known weaknesses. The password is the first factor, not the only one. Even the strongest password is pointless if the account has no second factor and the user gets phished.

For developers building the auth system itself, a handful of utilities come up constantly. TOTP Generator produces RFC 6238 time-based codes for testing 2FA flows without a physical device. HMAC Generator handles keyed hashes when you are debugging a signed request. UUID Generator and Random Generator produce unpredictable session identifiers. And when you need to sanity-check a leaked or shared credential, Base64 Encoder/Decoder strips the typical transport encoding without running the content on a server.

Related pillar guide

This cluster is part of the security track. For the full reference on threats, cryptography, OWASP, and the wider toolkit, see Web Security Tools: A Beginner's Masterclass.

FAQ

How long should a master password be?

A passphrase of 5–6 random words (EFF Diceware list) gives 65–77 bits of entropy, which is sufficient. A 20-character random password from the full ASCII set gives roughly 130 bits, which is overkill but future-proof. Pick whichever you can actually memorize; a password you forget is no security at all.

Is "password manager + one strong master" really safer than remembering separate passwords?

Yes, by a huge margin. The biggest real-world risk is reuse: the same password across ten sites means one breach compromises all ten. Password managers eliminate reuse. The master password is the single point of risk, so treat it seriously — passphrase, long, never typed on untrusted devices, with MFA on the manager itself.

Are biometric logins secure?

Face and fingerprint are convenient second factors. They are not a password replacement — biometrics cannot be changed if stolen. The modern right answer is passkeys (WebAuthn/FIDO2), which bind a cryptographic key to your device and unlock it with biometrics locally. You never type anything, nothing phishable crosses the network.

Should I periodically rotate my password manager master?

Only if you suspect compromise. Routine rotation has the same problems for master passwords as for any other — you will end up incrementing or simplifying. Focus on choosing a strong one once and protecting it.

Is Have I Been Pwned safe to use?

Yes, for checking whether an email has appeared in a known breach. Do not paste your actual passwords anywhere to "check" them. HIBP's password check uses k-anonymity — you send a hash prefix, receive matching suffixes, and compare locally — which is the right design. If a tool asks for your raw password to check it, walk away.

Closing thought

The password conversation is slowly being eaten by passkeys and other phishing-resistant authentication, and that is a good thing. Until then, the math is unambiguous: length and randomness matter, composition rules do not, KDFs on the server matter as much as the password itself, and humans should not be generating their own secrets. Open a password generator, let the browser roll a fresh random one, drop it in a manager, and never think about it again. That is the entire discipline.