How Strong Should Your Password Be?

Three years ago I watched a friend get his GitHub account compromised. His password was "Marcus2019!" and he thought the exclamation mark made it secure. An 8-character base with a year and a symbol. The attacker cracked it in under an hour using a modified dictionary attack. That's when I started actually understanding the math behind password strength.

Entropy in Plain English

Entropy measures unpredictability. In passwords, it's measured in bits. Each bit doubles the number of possible combinations an attacker has to try. A password with 40 bits of entropy has 2^40 possible combinations, roughly 1 trillion. A password with 80 bits has 2^80 combinations, roughly 1.2 sextillion.

The formula is simple. Take the number of possible characters in your pool, and raise it to the power of your password length. Then take the log base 2 of that number. For a 12-character password using uppercase (26), lowercase (26), numbers (10), and symbols (33), the pool is 95 characters. Entropy = log2(95^12) = about 79 bits.

That sounds abstract, so here's what it means practically. Every additional bit of entropy doubles the time needed to crack your password by brute force. Going from 60 bits to 70 bits doesn't add 10 more minutes. It multiplies the cracking time by 1,024.

The Brute Force Math

10 billion guesses per second

A single NVIDIA RTX 4090 can compute roughly 150 billion MD5 hashes per second. For bcrypt with a work factor of 12, that drops to about 65,000 per second. For Argon2id with recommended settings, it's even lower. The hash algorithm matters enormously.

But let's use a realistic middle ground: 10 billion guesses per second. That's what a determined attacker with a GPU cluster can achieve against SHA-256 hashed passwords (which many services still use). Here's what different password lengths look like at that speed:

8 characters (mixed): 95^8 = 6.6 quadrillion combinations. At 10B/sec, that's 7.6 days to try every single one. Average crack time: 3.8 days. In practice, attackers use optimized patterns and crack most 8-char passwords in under an hour.

10 characters (mixed): 95^10 = 59.8 quintillion. About 190 years to exhaust. Still, pattern-based attacks reduce this significantly.

12 characters (mixed): 95^12 = 540 sextillion. About 1,712 years to exhaust. Even optimized attacks struggle here. You're safe from brute force.

14 characters (mixed): 95^14 = 4.8 octillion. About 15 million years. At this point, the sun burns out before your password cracks.

Length beats complexity

Here's something most people get wrong. They think "P@$$w0rd" is strong because it has symbols. It's not. It's a dictionary word with common substitutions that every cracking tool checks first. Meanwhile, "correcthorsebattery" with just lowercase letters but 20 characters is astronomically harder to brute force.

Each additional character multiplies the keyspace by the pool size. Going from 12 to 14 characters (adding just 2 characters) multiplies the combinations by 9,025 when using the full 95-character set. That single change takes you from "crack in millennia" to "crack never."

This is why modern password guidance from NIST (Special Publication 800-63B, updated 2024) emphasizes length over complexity. They dropped the requirement for mandatory special characters and instead recommend a minimum of 8 characters with a strong preference for 15+.

Why 8 Characters Is Dead

The 8-character minimum comes from a time when attackers used CPUs and could manage maybe 10 million guesses per second. At that speed, 8 characters with mixed types took years to crack. GPUs changed everything. A $1,500 graphics card today does what would've required a supercomputer in 2005.

Hashcat, the most popular password cracking tool, running on a single RTX 4090 cracks any 8-character NTLM hash in under 60 minutes. Not days. Minutes. An 8-character password against MD5 hashing? Under 40 minutes for the entire keyspace.

If any service still enforces an 8-character maximum (yes, some banks do this), your security depends entirely on their rate limiting, not your password strength. And rate limiting fails if the hash database gets leaked. Which happens regularly.

The Passphrase Alternative

Random passwords like "j7$kL2!mP9" are strong but impossible to remember. Passphrases solve this by combining random words. "purple-telescope-salmon-fourteen" is 33 characters long and easy to visualize.

The Diceware method uses a list of 7,776 words. Four random words from this list give you log2(7776^4) = about 51 bits of entropy. Five words give you 64 bits. Six words give you 77 bits. For most use cases, 5 words is the sweet spot: strong enough for offline attacks and memorable enough to type.

The key word is "random." Picking words yourself ("correct horse battery staple" is famous now and in every cracking dictionary) isn't random. You need actual randomness from a generator. Human brains are terrible at randomness. We pick patterns, favorite words, related concepts. Attackers know this.

I use passphrases for my password manager master password and any password I need to type frequently. For everything else, I let the generator create a 16+ character random string and never look at it again.

Why Math.random() Is Not Enough

If you're building a password generator (or using one), the randomness source matters as much as the password length. JavaScript's Math.random() is a pseudorandom number generator (PRNG). It produces numbers that look random but follow a deterministic sequence based on a seed value.

In V8 (Chrome's JavaScript engine), Math.random() uses xorshift128+. If an attacker can observe a few outputs from Math.random(), they can predict all future outputs. This isn't theoretical. Researchers have demonstrated this attack. A password generated with Math.random() is weaker than its entropy suggests.

The correct API is crypto.getRandomValues(). This uses your operating system's cryptographic random number generator, which collects entropy from hardware events: mouse movements, disk access timing, network packet arrival times, CPU thermal noise. The output is cryptographically secure, meaning you cannot predict future values even if you've observed every previous one.

Our password generator uses crypto.getRandomValues() exclusively. Every random byte comes from your OS's entropy pool. The code runs entirely in your browser. No network request, no server-side generation, no seed that anyone can predict.

My Password Rules After 10 Years in Tech

After a decade of dealing with breaches, credential stuffing attacks, and watching colleagues get owned, here's what I actually do.

Rule 1: Every password is unique. Generated randomly. Stored in a password manager. I use 1Password but Bitwarden works just as well for free. I don't know any of my passwords except the master passphrase.

Rule 2: Minimum 16 characters for generated passwords. The storage cost is zero (password manager handles it), and the security gain from 12 to 16 characters is massive. There's no reason to go shorter.

Rule 3: The master passphrase is 5 random Diceware words with a number between two of them. Something like "marble-tundra-47-fossil-lantern." About 72 bits of entropy and I can type it from memory.

Rule 4: Enable 2FA everywhere that supports it. TOTP (Google Authenticator, Authy) as minimum. Hardware keys (YubiKey 5) for email and password manager. SMS-based 2FA is better than nothing but vulnerable to SIM swapping.

Rule 5: Check HaveIBeenPwned quarterly. Not because I reuse passwords (I don't), but because breached accounts tell me which services have weak security and might need extra attention.

The password strength checker on our site gives you instant feedback on entropy and estimated crack time. Pair it with the generator to create passwords that would outlast civilizations. The math doesn't lie, and the math says length wins.