Most advice about passwords is written as if “strong” were a feeling. Add a symbol. Make it longer. Don’t use your dog’s name. None of it tells you what a password is worth against an attacker with a GPU, which is the only measurement that matters once a hash database leaks.
This post puts a price on it: a guess rate, a keyspace, and a cost in dollars on rented hardware, instead of a vague “would take centuries.” If you already know how hashes are stored and which tools exist, you can skip straight to the numbers. If you don’t, my earlier post on how password cracking works and what defenders need to know covers storage, tools, and attack modes. This one is about economics.
Scope note: everything here applies to hashes you generated yourself, or that you are explicitly authorized to audit. That means your own lab, your own company’s password audit with written sign-off, or a sanctioned contest. Cracking someone else’s stolen data is a crime, and the numbers below are not an invitation.
The Only Two Numbers You Need
Cracking cost comes down to two things:
- Keyspace: how many candidate passwords the attacker has to try. A password drawn from 95 printable characters with 8 positions has 95⁸, about 6.6 quadrillion possibilities.
- Guess rate: how many candidates per second the hardware can test against your specific hash type.
Time to exhaust the keyspace is just keyspace divided by rate. Everything that follows is that one division, repeated for different hash types and password shapes.
The guess rate varies by a factor of millions depending on how the password was hashed, and that decision belongs to whoever built the system, not to the user.
Guess Rates: Fast Hashes vs. Slow Hashes
Published hashcat benchmarks for a single consumer RTX 4090 look like this:
| Hash type | Approx. rate (one RTX 4090) | Where you’d find it |
|---|---|---|
| NTLM | ~288 billion/sec | Windows local accounts, Active Directory |
| MD5 | ~156 billion/sec | Legacy web apps, old breaches |
| SHA-256 (unsalted/fast) | ~21.8 billion/sec | Poorly designed “modern” apps |
| bcrypt, Argon2, scrypt | thousands to hundreds of thousands per sec, depending on cost settings | Properly designed password storage |
The first three rows come from community benchmark results posted to the hashcat forum and summarized in TechSpot’s coverage; exact figures shift a few percent with drivers, clocks, and cooling. I’m deliberately not printing a single bcrypt number: it depends entirely on the cost factor the application chose, and published figures vary by orders of magnitude for exactly that reason. You’ll measure your own below.
The gap is the whole story. NTLM is about 13 times faster to attack than SHA-256 on the same card, and a well-configured bcrypt hash is slower than either by a factor of tens of thousands to millions. That ratio is what you’re buying when you choose a storage algorithm.
Time-to-Crack on One GPU (Fast Hashes)
Here is the full-keyspace brute-force time for a single RTX 4090 against NTLM, using the benchmark rate above. These are worst-case times to exhaust every possibility; the expected time to hit a random password is about half. Cost assumes about $0.30 per GPU-hour, explained in the next section.
| Length | Lowercase (26) | Lower+digits (36) | Mixed case+digits (62) | All printable (95) |
|---|---|---|---|---|
| 8 | under 1 second | 10 seconds | 12.6 minutes (~$0.06) | 6.4 hours (~$2) |
| 10 | 8.2 minutes | 3.5 hours (~$1) | 33.7 days (~$240) | 6.6 years (~$17,000) |
| 12 | 3.8 days (~$28) | 190 days (~$1,400) | 354 years | 59,000 years |
An 8-character mixed-case-and-digits password, the kind that passes most corporate complexity rules, falls to a single rented GPU in about thirteen minutes if the hash is NTLM. An 8-character password using every printable symbol takes about six hours and roughly two dollars.
For SHA-256 at 21.8 GH/s everything is about 13 times slower, which turns the 8-character all-printable case into 3.5 days (~$25) and the 10-character mixed-case-plus-digits case into 1.2 years (~$3,200).
And this is a single card. Attackers rent eight at a time, and the scaling is linear: eight GPUs cut every time above by a factor of eight.
What Slow Hashing Changes
Now compare the same 8-character mixed-case-and-digits password under bcrypt. Hive Systems’ 2025 password table assumes a twelve-GPU RTX 5090 rig attacking bcrypt at work factor 10, and puts that exact password at roughly 62 years, against about thirteen minutes on one card for NTLM. Heise’s write-up shows the rest of their table: eight lowercase letters take weeks, and an eight-digit numeric password still falls in about fifteen minutes even against bcrypt.
Two takeaways, and they pull in opposite directions:
- Slow hashing buys enormous time for passwords of reasonable strength. Same password, same attacker, thirteen minutes versus decades.
- It does nothing for weak passwords. A short numeric PIN-style password is gone in minutes regardless of algorithm, because the keyspace is tiny.
This is why password policy and storage design are one problem, not two. A strong storage algorithm protects a decent password from a leak. A strong password protects an unlucky one from a weak algorithm. You want both, and you only control one of them as a user.
Cost factor: the dial defenders forget
bcrypt’s cost parameter is exponential: each +1 doubles the work. Going from cost 10 to cost 12 makes every guess four times slower, for the attacker and your login server alike. Plenty of applications still run the library default from years ago. If you maintain anything that stores passwords, checking the cost factor against current hardware is a ten-minute task with a very large payoff.
What It Costs to Rent the Hardware
Cracking at scale is a rental business now. When I need serious GPU time, I don’t run it locally: my own hardware is a GTX 1080 and an RTX 2060, both old enough that benchmarking them would tell you nothing useful about what an attacker actually has, so for heavy jobs I rent GPUs on vast.ai instead. The economics explain why.
Current published pricing has Vast.ai listing an RTX 4090 from about $0.31 per GPU-hour on demand, with interruptible instances cheaper still and the typical range around $0.25 to $0.40. (Marketplace prices move daily; treat my $0.30 as a planning figure, not a quote.) That’s the figure used in the cost columns above.
Think about what that means for the threat model. The 8-character all-printable NTLM case costs about the price of a vending-machine snack. The attacker doesn’t need to own anything, doesn’t need to be skilled at hardware, and can stop paying the instant the job finishes. Provider acceptable-use policies vary, so read them before you rent anything for a legitimate audit, and keep the work to hashes you own.
What Renting Looked Like in Practice
For the Crack Me If You Can write-up, we spun up two vast.ai hosts with 4090 cards, and they worked well. The surprise was not the GPU speed, it was data movement. Our big wordlists were large enough that copying them to a rented host cost real time, and on a rented box the clock is also the bill. Every hour spent pushing a multi-gigabyte file over the wire is an hour you pay for and don’t crack anything.
So we split the work. The large wordlists stayed on my local machines, which are slow but free to leave running. The smaller, targeted wordlists went to the vast.ai hosts, where the fast cards could chew through them quickly. For a contest with a deadline that split worked well, and I’d do it the same way again.
If you plan to rent, put transfer time on the cost sheet next to the hourly rate. A small, well-aimed list on a fast card beats a huge list you spent the first hour uploading. It’s also the reason the targeted approach below matters so much: a smarter list is cheaper than more hardware.
Attackers Don’t Brute-Force
Every time above assumes the attacker tries every possible combination in order. Real attackers almost never do. They try likely passwords first: wordlists built from previous breaches, mutations of those words (capital first letter, 1! on the end, a→@), and patterns like keyboard walks and years.
That’s why a 12-character password built from a dictionary word plus decoration can fall in minutes, while a random 12-character string takes centuries. The brute-force table is a worst case for random passwords. For human-chosen ones, the real number is far lower.
My write-up of Crack Me If You Can 2026 shows this in practice. The biggest lever in that contest wasn’t raw keyspace exhaustion: it was noticing that each password was a themed concept expressed through the user’s own surname, a pattern hiding in the usernames. The same write-up makes the economic point from the other direction. The scoring rewarded choosing which hashes to chase, and one yescrypt crack outweighed thousands of raw-MD5 cracks, so GPU time went where the points-per-hash were highest. That’s the cost table in competitive form: the same hardware is worth very different amounts depending on the hash it’s pointed at.
The cost tables tell you the cheapest possible attack. The contest tells you what actually happens first.
Measure Your Own Hardware
Don’t take my numbers on faith. Benchmark your own setup, which takes a few minutes:
hashcat -b -m 1000 # NTLM
hashcat -b -m 0 # MD5
hashcat -b -m 1400 # SHA-256
hashcat -b -m 3200 # bcrypt
Then compute your own times: keyspace divided by your reported H/s. Run it on any rented instance too, since provider hardware, thermals, and drivers change results. Expect an older consumer card to land well below the 4090 figures. The speed ratio between hash types, which is the part that drives every decision in this post, holds on any GPU even when the absolute numbers move.
Reuse Is the Bigger Problem
After working with cracked hashes, the thing that stands out to me is not how fast a hash falls. It’s how often the same password turns up in more than one place. Reuse shows up constantly, across leaks, across sites, sometimes across the same person’s work and personal accounts.
Assume your password will be compromised at some point. A site gets breached, a hash gets cracked, or someone phishes you. You can’t control that. What you can control is how far it reaches. If that password protects exactly one account, the damage stops there. If it protects your email, your bank, and a forum you forgot about, one leak becomes all of them.
That is why I’d rank unique passwords above clever ones. A random 16-character password reused on five sites is weaker in practice than a mediocre unique one on each. The cost tables describe how hard it is to crack one hash. Reuse decides how many doors that one result opens.
What the Numbers Mean for Policy
Turn the economics into decisions:
If you run a system that stores passwords:
- Use a purpose-built slow algorithm (Argon2id, scrypt, or bcrypt) with a cost tuned to current hardware, and revisit it every year or two.
- Never use a fast general-purpose hash such as MD5 or SHA-256 for passwords, and never store unsalted hashes.
- Assume your database will leak someday and choose your algorithm for that day, not for the day it’s built.
If you set password policy:
- Length beats complexity. Moving from 8 to 12 characters changes the cost in the tables above from dollars to centuries, while adding a symbol to an 8-character password only changes it from minutes to hours.
- Check new passwords against breach corpora and block known ones. The brute-force tables assume random passwords; known-breached ones skip the keyspace entirely.
- Stop forcing rotation of strong passwords on a calendar. It pushes people toward predictable increments that fall to mutation rules.
If you’re a user:
- Use a password manager and let it generate long random passwords. A 16-character random password is beyond any of these attackers on any hash type.
- Use passkeys or a hardware security key where you can. A passkey has no password to crack at all.
- Treat the weakest hash your accounts might be stored under as the one that counts, because you can’t see how each site stores yours.
Limits of This Analysis
What these numbers don’t cover:
- They’re single-card, full-keyspace, uniform-random figures. Real passwords aren’t random and real attackers don’t enumerate in order, so treat these as a worst case for the defender only when the password is truly random.
- Benchmarks drift. Newer cards are faster; Hive Systems moved from 4090 to 5090 for their 2025 table and reported roughly a third more performance. Rates in this post will age.
- Salting matters at scale. Salts don’t slow a single targeted hash, but they stop an attacker from cracking a whole database in one pass, which changes the economics for large leaks.
- Rental prices are volatile, and cost per GPU-hour tells you nothing about electricity, setup, or the risk of renting for activity a provider might prohibit.
Wrapping Up
Cracking a password is an economic problem with a published price list. A fast hash and an 8-character password cost about the price of a coffee to defeat. A slow hash and a 16-character random password cost more than any attacker will ever spend. Almost everything in between is decided by choices that defenders make about storage and policy, long before an attacker ever opens a terminal.
If you take one action after reading this, make it this: find out what algorithm and cost factor protect the passwords you’re responsible for, and check them against the table above.
Sources: