How to Build a Password That Actually Survives a GPU Cracking Rig

Most password advice is folklore. "Use a capital letter, a number, and a symbol" became gospel around 2003 and stuck — even though the engineer who wrote the original guideline, Bill Burr, publicly regretted it in 2017. The math says something different, and once you see the math, you stop guessing.

This is a guide to the only thing that actually decides whether a password holds: how many possibilities an attacker has to grind through before they hit yours. That number is entropy, measured in bits, and it is computable. Let me show you how, then walk through where intuition leads people wrong.

Entropy is just a counting problem

A password's strength is not a vibe. It is one formula:

entropy = length × log₂(charset_size)

charset_size is how many distinct symbols each position could be. Lowercase only is 26. Add uppercase and you're at 52. Add digits, 62. Add the full set of printable ASCII symbols and you reach 95. Each position multiplies the search space; log₂ just converts that multiplication into additive bits so the numbers stay readable.

Worked example. Pick length 20, enable every character set, and generate:

Input:  length = 20, charset = upper + lower + digits + symbols (95 chars)
Output: J7&qm!Pv2@xZ#9rLt$Wn
Entropy: 20 × log₂(95) ≈ 20 × 6.57 = 131 bits

A real generator like the password generator shows this in a live meter as you type, so you watch the bits climb with every character. The reason 131 bits matters comes next.

Why "131 bits" means an attacker gives up

Bits of entropy map to guessing time through a brutal assumption: the attacker has your password's hash and grinds it offline at full speed. A modern GPU cluster does roughly 10¹¹ guesses per second (one hundred billion) against a slow hash like bcrypt. So:

crack_time = 2^entropy ÷ 10¹¹  (seconds)

At 131 bits, 2^131 ÷ 10^11 is about 10²² years — vastly longer than the age of the universe. The attacker doesn't crack it; they move to an easier target or try phishing you instead.

Now the cliff. Drop to a typical 8-character "complex" password from a 62-char set: 8 × log₂(62) ≈ 48 bits. That's 2^48 ÷ 10^11 ≈ 0.8 seconds. The symbol-and-capital password your bank demanded falls in under a second. This is the whole reason the thresholds in the generator's meter sit where they do: under 28 bits is Very Weak, 60–127 is Strong, and 128+ is Excellent. Those bands aren't arbitrary — they're the offline-attack survival line.

Length beats complexity, and it isn't close

Here's the counterintuitive part. Adding character sets gives you a one-time bump to charset_size inside a logarithm, so its effect is small and capped. Adding length multiplies the whole exponent. Compare two passwords from the same 62-character alphabet:

• 8 characters: 8 × log₂(62) ≈ 48 bits → cracked in under a second
• 16 characters: 16 × log₂(62) ≈ 95 bits → about 10⁷ years

Doubling the length didn't double the strength — it squared the search space. Meanwhile, going from a 62-char set to the full 95-char set at length 16 only buys you 16 × log₂(95) ≈ 105 bits, a 10-bit gain for a much more annoying-to-type password. Length is the cheap lever. Complexity is the expensive one. This is also why NIST SP 800-63B, the U.S. federal digital-identity guideline, dropped mandatory complexity rules and forbade periodic forced rotation, instead telling systems to allow long passwords (at least 64 characters) and to screen against breach lists. The standards body did the same arithmetic and reached the same conclusion: stop torturing users with symbols, let them go long.

Passphrase versus random string: a real tradeoff

If long is good and memorable is good, why not a passphrase — correct-horse-battery-staple? Because the entropy of a word sequence depends on the size of the word list, not the length of the string.

passphrase_entropy = word_count × log₂(vocabulary_size)

A 4-word phrase from the standard 2048-word Diceware list gives 4 × log₂(2048) = 44 bits — comparable to that weak 8-char password, despite looking long and friendly. To clear the Strong band you need 6+ words. A serious tool like the Diceware passphrase generator draws from a large vetted word list precisely so each word contributes the full ~11 bits.

So which wins? It's not strength, it's recall. A 20-character random string maxes out raw entropy but you'll never memorize it — paste it into a password manager and forget it. A 6-word passphrase tops out lower but you can hold it in your head, which makes it the right choice for the two or three secrets you must type from memory: your vault's master password, your laptop login, your full-disk-encryption key. Use random everywhere a manager autofills; use a passphrase only where a human brain is the storage medium.

How I actually use this day to day

I keep a simple rule. For anything a password manager will remember for me, I generate a 32-character random string with every set enabled and never look at it again — the entropy meter reads ~210 bits and I copy it straight into Bitwarden. For the handful of secrets I have to type myself, I switch to passphrase mode, pull six words, and tack a digit and symbol on the end: river-amber-quiet-stone-forge-nine! at roughly 50 bits is something I can recall under stress at 6 a.m. when a server is down, and kR7!mQ9@zX2# is not. The one place I never compromise is reuse — every service gets its own freshly generated secret, because a breach at one site should teach an attacker nothing about my login anywhere else. Before trusting a password I already had lying around, I run it through a password strength checker to see its real bit count instead of assuming the capital letter saved me.

The setup that makes the numbers honest

One detail underpins all of this: the randomness source. The entropy math only holds if every character is genuinely unpredictable. Math.random() in a browser is a pseudo-random generator seeded from a small (often 64-bit) state — observe a few outputs and an attacker can reconstruct the seed and predict the rest. A real generator uses crypto.getRandomValues(), which pulls from the operating system's cryptographically secure RNG, the same source that mints your TLS session keys. That's the difference between "131 bits" being a true measure of an attacker's pain and being a comforting lie. When you pick a generator, that one function name is the thing to check.

The takeaway is small enough to keep: go long before you go complex, let a manager hold the long ones, keep a passphrase only for what your memory must carry, and make sure the bits are real before you trust the meter.

---

Made by Toolora · Updated 2026-06-13