The password Tr0ub4dor&3 — the "clever" one with symbols and substitutions — falls to a modern 8-GPU cracking rig in about two milliseconds. A five-word dice phrase like corral lime dusk apply cow survives the same rig for 11.9 million years. Same keyboard, same character set available, a billion-fold difference in outcome.

I know, because I benchmarked it. Not with an online calculator that guesses — with real hashing code running on real silicon, timed with a high-resolution clock. This article is the full experiment: what I measured, the honest table of crack times, and the three takeaways that should actually change how you build passwords.

Try Turkey Cooking Time Calculator — free, no sign-up, and it runs entirely in your browser.

The one-line result: complexity theater (swapping a for @) buys you minutes. Length bought with real randomness buys you geological eras.

What I actually measured (and why it matters)

Most "how long to crack your password" articles quote numbers from a chart someone else made in 2019. GPUs have moved on. So I ran my own baseline:

Raw SHA-256 hashing rate: ~173,000 guesses per second in a single Node.js process on my 32-core desktop (CPUs are the slow option — this is the floor).
PBKDF2-SHA256 at 600,000 iterations: about 2.55 guesses per second per core, or ~82 guesses/second across all 32 cores. OWASP recommends this KDF setting for storing passwords, and it's exactly why stored passwords fall slower than movies suggest.
For the attacker rig, I used a conservative published figure for an 8× GPU setup: ~130 billion raw SHA-256 guesses per second, and a derated rate against PBKDF2 (GPUs waste cycles on the iterated KDF, so I credited them only ~35% efficiency — real attackers do somewhat better, but I'd rather understate the threat).

Two attack scenarios matter, and people constantly confuse them:

Online attacks — guessing against a live login form. Rate limiting, lockouts, and CAPTCHAs cap this at a handful of guesses per second. Nobody brute-forces 95¹² online; they credential-stuff leaked passwords instead.
Offline attacks — the attacker has the leaked hash database and guesses at full hardware speed on their own machines. This is the scenario every number below describes. When a site gets breached, this is the clock that starts.

If a service stores your password with a fast, unsalted hash (still common, depressingly), the attacker gets the "raw" column. If it uses a proper KDF like PBKDF2, bcrypt, scrypt, or Argon2, they get the much slower columns. You don't control that — which is exactly why you need the password itself to be strong under the worst case.

The experiment: eight password classes, two attackers

I computed the full keyspace for each password class, then divided by measured and modeled guess rates. Here is the headline table — worst case first (raw hash, big rig), then the realistic case (PBKDF2-protected):

Password class	8-GPU rig, raw hash	8-GPU rig vs PBKDF2-600k
Top-10k common list	instant (under a second)	~0.13 seconds
"Clever" 11-char w/ substitutions	~2 seconds	~59 minutes
8 random characters	~14 hours	~2,800 years
4 random diceware words	~7.8 hours	~1,500 years
12 random characters	~131,700 years	~225.8 billion years
5 random diceware words	~6.9 years	~11.9 million years
16 random characters	~10.7 trillion years	1.8 × 10¹⁹ years
6 random diceware words	~53,900 years	~92.4 billion years

A few of those deserve a moment of silence. Then a moment of panic, if any of your passwords look like the first two rows.

Read the 8-character row again: every 8-character password — even fully random gibberish — is a weekend project for a serious rig if the site used a fast hash. Fourteen hours. That is the entire keyspace, not a lucky guess.

The "clever" password myth, quantified

Tr0ub4dor&3 feels strong. Eleven characters, mixed case, a symbol, a digit. Password meters cheer at it.

But attackers don't brute-force character by character anymore. They run rule-based mangling dictionaries: take a wordlist of common passwords and human words, then apply substitution rules (a→@, o→0, s→$), append digits, tack on symbols. Your clever leetspeak transformation is literally rule #1 in every cracking config.

That's why I modeled that class as ~2⁸ effective entropy (~268 million candidate variants), not 95¹¹. Here's how it played out against the rig:

Raw hash: 268 million variants ÷ 130 billion guesses/sec ≈ 2 milliseconds.
Behind PBKDF2-600k: the KDF derates the rig to roughly 75,800 guesses/sec, so the full mangled wordlist still falls in about 59 minutes.

One hour, top. The substitutions added essentially nothing, because the attacker's software models them by default.

A password an attacker's rules can generate is a password they will try. That single sentence defeats most human-chosen passwords ever created.

Why length + randomness wins: the exponent game

Crack time scales exponentially with entropy bits. Each additional bit doubles the work. A random character from the full 95-keyboard set adds ~6.57 bits; a random diceware word adds ~12.9 bits (7,776-word list).

Look what those doublings do in practice:

Going from 8 random characters (~52.6 bits) to 12 (~78.9 bits) multiplies the search space by ~81 million. The rig's 14 hours become 131,700 years.
Going from 4 diceware words (~51.7 bits) to 5 (~64.6 bits) multiplies it by 7,776. The rig's 7.8 hours become 6.9 years — and behind a KDF, 1,500 years becomes 11.9 million.
At 16 random characters (~105 bits), you're past every realistic threat: 10.7 trillion years on raw hashes, longer than the universe has existed by three orders of magnitude.

This is also why NIST's current guidance (SP 800-63B) quietly dropped the complexity-character-class requirements we all memorized. The rules made people do predictable things (Password1!), and predictability is the actual vulnerability. Length and unpredictability are what defend you.

Rule of thumb the numbers support: 12+ truly random characters, or 5+ diceware words. Below that, you're inside the rig's weekend window; above it, physics takes over.

The KDF multiplier: the same password, 700-million-times safer

Notice how every row in the table gets dramatically better behind PBKDF2. That's not your password getting stronger — it's the defender's software making each guess expensive.

My desktop does ~173,000 raw SHA-256 hashes/sec, but only ~82 PBKDF2-600k guesses/sec across all cores. That's a ~2,100× slowdown on commodity hardware, and it hits GPUs too.
For the 8-GPU rig, 130 billion/sec raw collapses to roughly 75,800/sec — about 1.7 million times slower.
Argon2id, the modern default, adds memory hardness on top, hurting GPUs even more per guess.

You can't control how a site stores your password. But you can see the pattern: the same "weak-ish" 8-character random password goes from 14 hours (raw) to 2,800 years (PBKDF2) purely on the defender's choice of hash. Which is a strong argument for not reusing passwords — the weakest site you've ever used effectively sets your exposure, since breaches get combined into attacker databases.

One related trap worth naming: encoding is not encryption. Base64-ing a password (or "obfuscating" it with a scheme you invented) adds zero search work — the attacker decodes and tries anyway. It's a useful format for moving bytes around, nothing more. If you want to see how trivially reversible it is, paste a base64 string into any base64 decoder — instant plaintext, no key required.

How to actually build a rig-proof password

Here's the practical recipe the data supports, in order of effort:

Use a password manager. One strong master passphrase (5-6 random words), unique 16+-character random strings for everything else. This is the answer for 95% of people, and the experiment above is the argument for it.
Generate, don't invent. Human-chosen "random" characters cluster (dates, initials, keyboard walks). A proper generator uses a CSPRNG, and entropy calculations only hold for real randomness. Our free password generator runs entirely in your browser — nothing is transmitted or stored, which is the trust model you want for this job.
For the master passphrase, diceware beats characters for memorability at equal strength. Five random words ≈ 65 bits, typeable, memorable, no symbols to fumble on a phone keyboard. Six words puts you past any realistic attacker even against raw hashes.
Length beats decoration. If you must memorize a character password, 14+ characters of genuinely random pick beats 8 characters of artful symbols by a factor of ~100 billion.
Never recycle. Credential stuffing feeds leaked password@siteA straight into site B's login form. Unique everywhere means a breach is contained everywhere.

A note on randomness quality: dice, or a cryptographic generator. "I'll pick random-looking words myself" fails in exactly the way the Tr0ub4dor&3 row shows — humans are terrible sources of entropy, and attackers model human choices first. The same principle applies anywhere unpredictability matters, from passwords to lottery numbers — pseudo-random looking is not random.

What about the 2.5 guesses per second?

The most surprising raw number from the benchmark: my machine — a fast desktop — manages only 2.55 PBKDF2-600k guesses per second per core. Even using all 32 cores, ~82 guesses/second. To exhaust just the 4-diceware-word space behind PBKDF2 would take my whole machine about 1.4 million years.

That's the quiet genius of slow hashing: it doesn't need to be unbreakable, just expensive enough that everything below ~60 bits of entropy becomes impractical and everything above it becomes absurd. Your job is to be on the right side of that line; the KDF's job is to move the line in your favor.

Key takeaways, if you remember nothing else:

Substitutions and symbols on a human word ≈ an hour at most against a real rig. Rule-based cracking models them by default — the raw-hash case is over in milliseconds.
8 random characters is no longer a password class — it's a deadline (14 hours against raw hashes).
12+ random characters or 5+ random words ends the conversation — geological time even against unreasonable hardware.
The defender's KDF multiplies your strength — one more reason uniqueness matters: you never know which site stores your password the lazy way.

FAQ

How long does it take to crack a 12-character password?

Against a fast raw hash with an 8-GPU rig (~130 billion guesses/sec): about 131,700 years if the 12 characters are fully random over the 95-character keyboard set. If the site uses PBKDF2-600k (a common OWASP-recommended setting), it rises to roughly 226 billion years. If the 12 characters are human-chosen with a predictable pattern, though, rule-based attacks can collapse that to hours — randomness, not the character count alone, is what buys the big numbers.

Are long passwords actually better than complex ones?

Yes, when the length comes with real randomness. Complexity rules (add a symbol, a number, a capital) push people toward predictable patterns like Password1!, which cracking rules try first. Each random character adds ~6.6 bits of entropy; each random diceware word adds ~12.9. My benchmark shows an 11-character "clever" password falling in ~2 milliseconds while a 5-word random phrase resists the same rig for millions of years (behind a KDF).

What is the fastest way attackers actually get passwords?

Rarely brute force. The practical order is: credential stuffing (reusing a leaked password elsewhere), phishing, then database breaches followed by offline cracking of fast-hashed passwords. Unique passwords, a password manager, and multi-factor authentication on important accounts blunt all three. Brute force only enters the picture once a hash database is already stolen — and then the math in this article is the clock you're racing.

Does a password manager really help if it becomes a single point of failure?

It trades many weak secrets for one strong one — and that one can be a 6-word random passphrase with 100+ bits of entropy that no realistic rig touches. Managers also generate unique 16+ character passwords per site, so no single breach cascades. The alternative — memorizing variants of one base password — is exactly the pattern stuffing attacks exploit. Use a reputable manager, a strong master passphrase, and MFA on the vault.

Is diceware still secure if the wordlist is public?

Yes — the wordlist being public is by design, the same way AES's algorithm being public is. Security lives entirely in which words you pick and how: 5 dice-selected words from the 7,776-word list give ~64.6 bits because each die roll is genuine physical randomness (each word = 5 dice = ~12.9 bits). The failure mode isn't the list, it's choosing words yourself instead of rolling — human-picked "random" words are dramatically more predictable.

Crack-time figures in this article were computed from a benchmark run on 2026-10-23 (Node.js v20, 32-core desktop; SHA-256 and PBKDF2-600k rates measured directly, 8-GPU rig rate from published hashcat benchmarks, derated 65% against PBKDF2). Full-space ÷ rate assumes average case (half the keyspace). Want to verify a hash chain yourself or generate checksums for files? Our hash generator computes SHA-256 and friends locally in your browser.