Dataset: the attacker numbers here come from public, downloadable sources you can check yourself: live Bitcoin network hashrate from Blockchain.com's open charts, and GPU cracking speeds from the openly published hashcat benchmarks.
Your password is almost never stored as your password. It is stored as a scrambled fingerprint of it, and the entire question of whether a stolen database hurts you comes down to how long a machine needs to guess its way back to the original. That number is not one number. It swings from instant to trillions of years depending on two things you half control and one you do not.
Here is the uncomfortable part. The famous password-strength tables that get passed around at work are mostly right and quietly out of date at the same time, because the answer depends entirely on which hashing algorithm a website happened to use, and hardware keeps getting faster. So let us do the actual math, map it as a heatmap, and then point the whole planet's worth of computing power at a single password to see what survives.
Where does your password actually live?
When you sign up somewhere, a responsible service never writes your password to disk in plain text. It runs it through a hash function, a one-way scrambler. The word password through MD5 always becomes 5f4dcc3b5aa765d61d8327deb882cf99, and there is no formula to run that backwards into password. The database stores the hash. If it leaks, an attacker sees fingerprints, not secrets.
So how does anyone get in? Two ways, and they are the two attacks this article measures: the lookup table and the brute force.
The first is a lookup table. Because a given input always produces the same hash, an attacker can pre-compute the hashes of every common password, leaked password, and dictionary word, store them in a giant table, then ctrl+F your leaked hash against it. These precomputed structures, including the optimized version called a rainbow table, turn cracking into a near-instant search. This is why 123456 and password fall the moment a database leaks: their hashes are already sitting in someone's table.
The defense is a salt, a unique random string generated per user and mixed into the password before hashing. You do not hash hunter2, you hash hunter2 plus x9f2a8, and you store the salt right next to the hash in the same row. The salt is not secret. An attacker who steals the database gets it too, and that is fine, because its only job is to make every stored hash unique.
That uniqueness is what breaks the lookup table. A precomputed or rainbow table works because one password maps to one fixed hash, so the attacker computes that universe of hashes once and reuses it against millions of stolen records. Add a per-user salt and that economics collapses. Two people with the password hunter2 now have completely different hashes, so a table built for the unsalted hunter2 matches neither. To use a precomputed table, the attacker would have to build a separate one for every salt, which is the same total work as just attacking each account from scratch. The shared shortcut is gone.
So salting does not make a weak password strong, and it does not slow down a single guess. What it does is change the attacker's whole strategy. Without a salt, one giant table cracks everyone at once. With a salt, that table is worthless and the attacker is forced into real brute force: pick a target account, read its salt, then hash candidate after candidate with that exact salt until one matches, and start over for the next account. The attack moves from a one-time ctrl+F lookup to per-user guessing, which is exactly the slow road the rest of this article measures.
Brute force is exactly what it sounds like. Generate every possible combination of characters, hash each one with the right salt, and watch for a match. No cleverness, just speed. And speed is where the hash function you never chose decides your fate.
| Hash function | Built for | One RTX 4090 guesses per second |
|---|---|---|
| MD5 | Speed (now unsafe for passwords) | ~164 billion |
| SHA-1 | Speed (deprecated) | ~50 billion |
| NTLM (Windows) | Speed | ~250 billion |
| SHA-256 | Speed | ~22 billion |
| bcrypt (cost 10) | Deliberate slowness | ~6 thousand |
Look at the bottom row. bcrypt is tens of millions of times slower to compute than MD5, on purpose. That is the whole game. A fast hash hands the attacker billions of guesses a second. A slow hash like bcrypt, scrypt, or Argon2 throttles them to a trickle. You do not get to pick which one a website uses, but it changes your crack time by a factor of about 30 million.
How fast can one computer guess?
Start with a single machine, because that is the threat most people actually face: a stolen database and one motivated person with a gaming PC.
A laptop CPU is a poor password cracker, managing a few million to a few hundred million guesses a second. The graphics card is the real engine. One high-end consumer GPU runs about 160 billion guesses a second against a fast hash like MD5. That is one card you can buy today, no datacenter required.
The chart below maps what that single GPU does to a randomly generated password, by length across the top categories of complexity. Green is safe, red is gone. Notice how little the character mix matters compared to length: adding two characters beats adding symbols every time.
| Length | Numbers (10) | Lowercase (26) | Mixed case (52) | Alphanumeric (62) | Full set (95) |
|---|---|---|---|---|---|
| 6 chars | Instant | Instant | Instant | Instant | 5 sec |
| 8 chars | Instant | 1 sec | 6 min | 23 min | 12 hours |
| 10 chars | Instant | 15 min | 11 days | 2 months | 12 years |
| 12 chars | 6 sec | 7 days | 78 years | 640 years | 107k years |
| 14 chars | 10 min | 13 years | 210k years | 2.5m years | 970m years |
| 16 chars | 17 hours | 8.6k years | 570m years | 9.5bn years | 8.7tn years |
- Instant
- Minutes to hours
- Days to months
- Years
- Thousands of years
- Effectively forever
Read the diagonal. An 8-character password with the full set of symbols falls in about 12 hours to one gaming PC, if the site used a fast hash. Your bank's "8 or more characters, one capital, one number" rule lands you squarely in the red. But push to 12 characters of the full set and that single GPU needs 107,000 years. Two extra characters is the difference between an afternoon and an ice age.
The catch is the phrase "fast hash." Every number in that table assumes the worst common case. If the site used bcrypt instead, multiply everything by roughly 30 million. That 12-hour 8-character password becomes about 40,000 years. Hive Systems, which rebuilds this table every year, now assumes bcrypt because that is what real breaches show, and pegs a random 8-character full-set password at 164 years against a 12-GPU rig. Same password, wildly different fate, decided by a choice you never see.
What if you threw the whole planet at one password?
One gaming PC is the realistic threat. But it is worth asking the extreme version: what if an attacker had absurd resources? What if they commandeered an entire hyperscale AI buildout, or the entire Bitcoin mining network, or every machine on Earth, and aimed all of it at one password?
Bitcoin gives us a real, live number. The global mining network currently runs at about one zettahash per second, roughly 10²¹ guesses, visible right now on the public hashrate charts. That is the single largest concentration of brute-force computing power humans have ever assembled, and it grew alongside the broader compute build-out we have tracked in the falling cost of hashing per dollar. So let us line up the attackers from your gaming PC up to the planet, against four real passwords.
| Attacker (guesses/sec) | 8 chars lowercase | 8 chars full set | 12 chars full set | 16 chars full set |
|---|---|---|---|---|
| Your gaming PC (10¹¹) | 1 sec | 12 hours | 107k years | 8.7tn years |
| Criminal 12-GPU rig (10¹²) | Instant | 22 min | 3.4k years | 279bn years |
| All of Google-scale compute (10¹⁸) | Instant | Instant | 6 days | 1.4m years |
| The Bitcoin network (10²¹) | Instant | Instant | 9 min | 1.4k years |
| Every machine on Earth (10²²) | Instant | Instant | 54 sec | 140 years |
- Instant
- Minutes to hours
- Days to months
- Years
- Thousands of years
- Effectively forever
Two findings jump out, one scary and one reassuring.
The scary one: a random 12-character full-set password, which most strength meters paint deep green, falls in under a minute if you could genuinely point every computer on Earth at it. Even all of Google-scale compute cracks it in under a week. Twelve characters is not the fortress people think it is against a determined nation-state with a fast hash to attack.
The reassuring one: 16 characters survives even the whole planet for 140 years, and survives a realistic criminal rig for 279 billion years. Four more characters moved you from "vulnerable to a state" to "safe against the species." Length is exponential, and exponential always wins.
Now the giant asterisk. This entire table assumes a fast, unsalted hash, which is the attacker's dream. Bitcoin's ASICs cannot even run bcrypt; they only do SHA-256. The moment a site uses a salted slow hash, you can mentally erase the Bitcoin and Google rows entirely, because that hardware either cannot run the function or crawls through it tens of millions of times slower. The planet-scale attack is a thought experiment. The gaming PC in the first table is the one that actually shows up.
Is the old advice about password strength wrong?
Not wrong. Aging. The classic advice baked in two assumptions that have drifted: that complexity beats length, and that the numbers in the table are fixed. Both have moved.
The complexity-first era gave us "Pa$$w0rd1" and a generation of forced quarterly resets. It optimized the cheap axis. As both heatmaps show, adding character types is a linear nudge while adding length is exponential. The United States standards body NIST quietly rewrote its guidance to match: its updated digital identity guidelines drop mandatory complexity rules and periodic forced resets, tell verifiers to allow long passphrases of 64 characters or more, and push screening against lists of breached passwords instead. The official advice caught up to the math. A lot of corporate password policies have not.
The second drift is hardware, and it cuts against the scary tables, not for them. The most-shared password tables online still assume MD5 and a single GPU, which describes 2015, not today's reality where most serious breaches show bcrypt. So those tables can be alarmist about strong passwords and complacent about the thing that actually matters, which is the hash you cannot see. Here is the honest read for what to do:
- Length is the lever. A random 16-character password is safe against any attacker in this article, on any hash, for the rest of your life. Aim there.
- Use a manager. Random beats clever. The crack times above assume randomly generated strings, and humans cannot generate randomness. A reused or dictionary-based password skips the brute force entirely through that lookup table from the start of this piece.
- You do not control the hash, so over-provision. Since you cannot know if a site uses MD5 or Argon2, pick a length that survives even the fast-hash, all-of-Earth column. That means 16 or more.
- Turn on a second factor. Every number here assumes the attacker only needs the password. A second factor means a cracked hash is often worthless.
The "consensus" was built for a world of fast hashes and slower computers. Both halves of that have changed, in opposite directions, which is exactly why a single magic password length feels both reassuring and never quite settled.
The real takeaway is smaller than a number. You cannot control whether a company salts and slow-hashes your password, whether their database leaks tonight, or whether someone points a warehouse of GPUs at it next year. You can control one variable, and it happens to be the exponential one. Make it long, make it random, and let the math do the rest.
