When a website tells you your password would take three million years to crack, it’s leaving out the important half of the sentence. The right question isn’t how long. It’s how long against what.
And the answer to against what isn’t yours to make. It was made by a developer at the shop where you bought a pair of trainers in 2019, the day he chose how to store your password in his database. You typed the same twenty-character string into both sites. On one it holds for centuries; on the other it’s gone before lunch.
The number missing from the equation
A brute-force attack is grubby arithmetic: number of candidates you have to try, divided by candidates you can try per second. The first factor depends on your password — its length, its alphabet, whether or not it’s sitting in a dictionary. The second has absolutely nothing to do with you.
The second factor depends on two things: the attacker’s hardware and, above all, the function the site used to turn your password into the gibberish it keeps in its users table. That function is called a hash, and they don’t all cost the same to compute.
MD5 and SHA-1 were designed to be fast. That’s a virtue: they’re general-purpose hash functions, meant for digesting messages and checking integrity, and there what you want is to chew through a gigabyte before you’ve had time to go make coffee. When someone uses them to store passwords, the virtue becomes the problem. A function you can compute millions of times a second is a function the attacker can also compute millions of times a second — and he has graphics cards and the whole weekend.
bcrypt and Argon2 were designed with the opposite goal. They’re slow on purpose, and — this is the elegant part — slow by a dial you can turn. Niels Provos and David Mazières introduced bcrypt in 1999 under a title that says it all: A Future-Adaptable Password Scheme. The idea was that the function could be made more expensive over the years, keeping pace with hardware getting cheaper. Argon2, which won the Password Hashing Competition in 2015, added another twist: it doesn’t just cost time, it costs memory, which happens to be exactly what GPUs are least generous with.
Between a fast hash and a well-tuned slow one, the difference isn’t measured in percentages. It’s orders of magnitude. Plural.
The benchmarks exist, and they’re public
None of this is speculation. Hashcat, the tool half the world uses to crack passwords — the good half included — ships with a benchmark mode anyone can run on their own machine, measuring algorithm by algorithm how many times per second each one can be computed. The community publishes those tables every time a new GPU lands.
The interesting thing about those tables isn’t any particular number — which expires with each hardware generation anyway — it’s the distance between the rows. Sort the list by speed and you’ll find MD5 right at the top, on its own private planet. Keep scrolling down, and at the bottom of the table sit bcrypt and Argon2, with figures that look nothing like it. Same password. Same GPU. The only thing that changed is how the site decided to store it.
That’s why “3 million years” without naming a hash is marketing, not a measurement. It’s like advertising that your car gets there in six hours without mentioning where.
Offline and online: two worlds that never touch
There’s a second distinction almost nobody explains, and it swings the result just as brutally.
In an online attack, the attacker tries passwords against the login form, the way a user would. The pace isn’t set by his hardware: it’s set by the server. There can be attempt limits, temporary lockouts, a captcha, delays between requests, alerts when a thousand failures come from the same address. Against a halfway-defended site, an online attack is slow, loud and fairly stupid. The arithmetic is so bad for the attacker that pure brute force is barely attempted at all: instead he tries the same four passwords everyone uses against millions of accounts, which is a different game entirely.
In an offline attack, the attacker already has the database dump. He takes it home. There’s no server there, no attempt limit, nobody watching: just his graphics cards and his electricity bill. He can grind for months without anyone finding out, and he’ll know he’s got it all by himself, by comparing hashes. This is where the hash decides everything, because the hash is literally the only thing slowing him down.
And it’s worth being honest about the odds here: the offline scenario isn’t exotic. It’s what happens every single time a database leaks. When LinkedIn lost theirs in 2012, analysis of the leaked dump showed the passwords had been stored with SHA-1 unsalted: a fast hash, missing the one ingredient that stops you precomputing tables. That so many fell, and fell so fast, wasn’t just users picking badly. It was, above all, an engineering decision no user ever laid eyes on.
What we do here, and why we say so
Our checker assumes 10¹² guesses per second, offline, against a fast hash. It says so on the page itself, right under the result, and not as decorative transparency: without that number, the time it shows you means nothing.
It’s deliberately the bad case. We assume the database has already leaked, that the attacker has serious hardware, that the site stored your password in the worst way it reasonably could, and that on top of that he knows your alphabet and your length. If the site used properly configured bcrypt, the real figure climbs many orders of magnitude and your password holds out far longer than we tell you.
We’d rather be wrong in that direction. A checker that congratulates you is congratulating itself.
The uncomfortable conclusion
Your password doesn’t have a time-to-crack. It has a time-to-crack for every site you’ve ever used it on, and that time is set by people you’ve never met, using criteria they don’t publish.
From which two things follow, and they’re the usual two. First: since you can’t control the hash, control the entropy, which is the half of the equation that is yours — that’s why the generator shows you bits and not some cheerful percentage. Second, and more important: if every site gets its own password, the one that stored it in MD5 can only give away that site’s.
Because the weak link isn’t your password. It’s the worst site you ever typed it into.
Sources: public hashcat benchmarks (hashcat -b), checkable and reproducible · N. Provos and D. Mazières, “A Future-Adaptable Password Scheme”, USENIX, 1999 · Password Hashing Competition, won by Argon2 in 2015 · the threat model declared in the password.es checker: 10¹² guesses/s, offline, fast hash · 2012 LinkedIn breach: the company confirmed the leak, and the use of unsalted SHA-1 was established by analysing the published dump.