Password Crack Times

The 5-Million-to-One Gap

Here is a sentence that should bother you: an 8-character password protected by bcrypt outlasts a 20-character password protected by raw SHA-256. Not "outlasts" in the marginal sense — "outlasts" as in the bcrypt-protected 8-character password takes years to crack on enterprise hardware, while the SHA-256 20-character password falls in hours.

The gap in hash rates between the slowest and fastest algorithms is not 2× or 10× or even 100×. A single RTX 4090 running hashcat can push roughly 25 billion SHA-256 hashes per second. The same card, against bcrypt at cost factor 12, manages about 5,000 hashes per second. That is a factor of 5 million. Five. Million. To. One.

Nobody talks about this. Password security advice has been stuck on a loop since 2004: use uppercase, lowercase, digits, symbols, and at least some number of characters that creeps up every few years. That advice assumes the hash function is a constant — that "how long to crack a password" is purely a function of length and character set. It isn't. The hash algorithm is the dominant variable. It swamps everything else.

I built the password crack time estimator on this site to make the algorithm gap visible — to let you toggle between bcrypt and SHA-256 and NTLM and watch the crack time jump by orders of magnitude while the password stays the same. This article is about why that gap exists, how big it really is across different attacker profiles, and what it means for anyone who stores passwords — which, in 2026, is everyone running a web service, a database, or an authentication system.

Why Hashes Differ: It's a Feature, Not a Bug

To understand the gap, you have to understand why SHA-256 and bcrypt exist in the first place. They were built for opposite purposes, and the performance characteristics reflect that.

SHA-256 was designed by the NSA and published by NIST in 2001. Its job is to take an arbitrary amount of data and produce a fixed-size 256-bit fingerprint — fast. It is a general-purpose cryptographic hash. It runs in silicon efficiently because it uses simple bitwise operations that map cleanly to GPU instruction sets. Every GPU generation since Maxwell has been optimized for SHA-256 throughput because SHA-256 is used everywhere: TLS certificate verification, blockchain mining, file integrity checking, digital signatures. When you benchmark hashcat on an RTX 4090 and see 25 billion hashes per second, you are seeing the accumulated result of 20 years of hardware and software optimization for exactly this operation. It was never supposed to protect passwords. It was supposed to be fast. It is.

bcrypt was designed by Niels Provos and David Mazières in 1999 for exactly one job: password hashing. It is built on top of the Blowfish block cipher, modified with an expensive key schedule. The "cost factor" — a parameter you set when hashing — determines how many iterative rounds the algorithm runs: cost factor 12 = 2^12 = 4,096 iterations of the Blowfish key schedule, each one requiring multiple memory accesses that GPUs handle poorly. bcrypt was designed to be slow. And it was designed with a specific hardware asymmetry in mind: the defender hashes one password per login attempt and doesn't care if it takes 300 milliseconds. The attacker has to hash billions of candidate passwords. bcrypt makes each guess as expensive as possible for the attacker while staying fast enough that a user logging in doesn't notice the delay.

NTLM — Microsoft's legacy password hash, still in active use on Windows networks in 2026 — is even worse than SHA-256. It uses the MD4 hash function with no salt and no iteration count. A single RTX 4090 pushes roughly 100 billion NTLM hashes per second. That is 20 million times faster than bcrypt cost 12 on the same hardware. NTLM wasn't badly designed for its era — it was designed in 1993, when a "fast hash" was a feature and a GPU didn't exist. The world changed. NTLM didn't.

Here is the raw comparison across the algorithms in our password crack time estimator, benchmarked on a single RTX 4090 running hashcat in mid-2026:

Sources: Community hashcat benchmarks compiled June 2026. Raw SHA-256 and NTLM rates are measured with optimized kernels on RTX 4090. bcrypt and Argon2id rates vary with cost factor and memory parameters. These are approximate figures — exact rates depend on driver version, cooling, and workload — but the order-of-magnitude gaps are stable across hardware generations.

Look at the gap between bcrypt and NTLM again: 20 million to 1. That's the difference between a password that takes a year to crack and one that takes 1.5 seconds. The hash algorithm is not one factor among many. It is the factor. Length, character set, entropy — those matter at the margins. The hash function determines whether the attacker's problem is a brute-force problem at all, or just a matter of renting enough GPUs for long enough.

The Five Attacker Tiers: Hash Rates at Scale

A single RTX 4090 is a hobbyist. Real attackers scale horizontally. The password crack time estimator models five hardware profiles, and they produce qualitatively different threat models depending on which hash function you're defending against.

Hash rates for bcrypt assume cost factor 12 and scale linearly with GPU count — a simplification, as multi-GPU bcrypt cracking has communication overhead. SHA-256 and NTLM scale near-linearly. ASIC estimates are speculative — public data on state-level password cracking capacity is sparse for obvious reasons. Cloud cost estimates use approximate on-demand GPU pricing from providers listed in our GPU training cost estimator.

The important thing about this table is not the absolute numbers. It's that the attacker's hash rate multiplies by roughly 10× to 100× at each tier — but that only matters if the hash function is fast enough for the multiplication to make a dent. Against bcrypt, even a 10,000-GPU datacenter manages only 50 million guesses per second — roughly the speed of a single RTX 4090 running NTLM at one-two-thousandth the hardware. The defensive asymmetry built into bcrypt scales with the attacker's budget. Against SHA-256 or NTLM, the asymmetry runs the other way: every dollar the attacker spends buys them linearly more cracking power, because the hash function was designed to be fast on exactly the kind of hardware attackers rent.

This is why "how long to crack a 12 character password" is a meaningless question without naming the hash function. Against NTLM on a datacenter cluster, you get roughly 12 hours. Against bcrypt on the same hardware, you get centuries. Same password. Same character set. Same attacker. The only variable is the hash function.

The Economics of Cracking: Rent, Don't Build

Nobody reasonable builds a dedicated password-cracking datacenter. They rent one. The cloud GPU market — the same one modeled in our GPU training cost estimator — has made massive parallel compute available by the hour, no capital expenditure required. And this changes the economic calculus of password cracking from "can I afford the hardware" to "is the password worth the cloud bill."

Let's price out the cost to exhaust a full 8-character mixed-case keyspace (62^8 ≈ 2.18 × 10^14 combinations — average case: 1.09 × 10^14 guesses) across different hash functions, using cloud GPU rental at the Lambda Labs on-demand H100 rate of $2.49/hr. An H100 is roughly 2–3× faster than an RTX 4090 for hash cracking, so we'll give the attacker 15,000 bcrypt H/s and 75 billion SHA-256 H/s per H100.

These numbers assume the attacker needs to exhaust the entire keyspace — i.e., the password is truly random, not a human-chosen string. That assumption is false for most real passwords, as we'll get to. But for the random-password case — the API key, the generated secret, the machine credential — these dollar figures are the direct economic answer to "how safe is this password?" If cracking your password costs $5 million in cloud GPU time and the asset it protects is worth $50,000, the attacker has made a rational economic decision to walk away. That's the design goal of bcrypt and Argon2: make cracking uneconomical. With SHA-256 and NTLM, cracking is cheaper than the cloud instance it runs on.

The 12-Character Password, Deconstructed

This is the question that brings most people here: how long to crack a 12 character password? And the answer splits cleanly along the algorithm line. Let's use a password drawn from the full 62-character set (mixed case + digits, 62^12 = 3.23 × 10^21 combinations, ~71.5 bits of entropy) and run it through every attacker tier and hash algorithm simultaneously.

Calculated using the password crack time estimator. Average-case exhaustion = keyspace ÷ (2 × hash rate). ASIC estimates are speculative. Time values are full keyspace exhaustion — a randomly chosen password will be found on average at 50% of the keyspace, halving all times shown. Human-chosen passwords are cracked much faster via wordlist attacks regardless of algorithm.

The pattern is unmistakable. With bcrypt or Argon2id, a 12-character random password is uncrackable by any adversary that exists or will exist in the foreseeable future. With SHA-256, the same password falls to a datacenter-scale attacker in about two and a half months. With NTLM, it falls in under a day. The password did not change. The character set did not change. The length did not change. Only the hash function changed.

This is where toggling the algorithm selector in the estimator becomes genuinely instructive. Change bcrypt to NTLM on a 12-char password and watch the result go from "heat death of the universe" to "before lunch tomorrow." The gut-level reaction people have when they see that number flip is more educational than any password advice column ever written.

Where Brute Force Actually Matters

Most passwords aren't cracked. They're leaked. The 2024 Verizon DBIR found that credentials remain the most common entry vector in breaches, but the mechanism is rarely brute force — it's credential stuffing, phishing, or a plaintext password database exposed by a misconfigured S3 bucket. Against those attacks, your bcrypt cost factor doesn't matter because the attacker already has the plaintext.

The brute-force resistance of your hash algorithm matters in exactly one scenario: an offline attack on a stolen password database. This happens when an attacker obtains your password hash file — through SQL injection, a compromised backup, an insider, or a server breach — and then runs hashcat against it at their leisure with no rate limiting and no login attempt throttling. It's offline. It's quiet. And the only thing standing between the attacker and every user's plaintext password is the hash function you chose.

This is the scenario where the bcrypt-vs-SHA256 gap stops being an academic comparison and becomes the difference between "we need to notify users to change their passwords" and "we need to notify users that their passwords are already being sold in bulk." If your database was stolen yesterday and you used bcrypt cost 12, the attacker can try maybe 5,000 guesses per second per GPU against each hash. They'll crack the weak passwords — password123, the company name, the user's own email prefix — within seconds via wordlist attack, and then they'll move on to the next database. The strong passwords in your database will remain uncracked because the economics don't work. If you used SHA-256, they'll crack every single password in the database, including the 20-character ones, because at 25 billion guesses per second per GPU, the economics flip: cracking the entire database costs less than the attacker's lunch.

This also means the password length arms race — "use 8 characters, no wait, 10, no wait, 12, no wait, 16" — is fighting the wrong battle. If your hash function is bcrypt or Argon2id, 12 truly random characters is already uncrackable at any scale. Adding characters beyond that buys you nothing in practical security terms. If your hash function is NTLM, even 20 characters is a speed bump against a datacenter-scale attacker. Use the estimator to find the crossover point for your specific threat model — for most people, it's somewhere between 8 and 12 characters with bcrypt, and the real question isn't "how long" but "what hash function."

The UUID collision estimator works on a related principle — probability ceilings that look absurd until you do the math — and the same conceptual mistake shows up in both domains: people optimize the visible variable (password length, UUID count) while ignoring the structural variable that dominates the outcome (hash algorithm, UUID version).

Choosing a Hash: The Practical Guide

If you're building something that stores passwords — a web app, an API, an internal tool, anything with a user table — here is the decision framework, stripped to what matters:

Use Argon2id if you can. It won the Password Hashing Competition. It is memory-hard (resists GPU parallelism), side-channel resistant, and configurable. The OWASP recommendation (2026): Argon2id with 2 iterations, 64 MiB memory, 1 degree of parallelism. Tune the memory parameter to the maximum your authentication server can handle — make the attacker pay for every byte of RAM your hash requires, because GPUs are fast but GPU memory bandwidth per hash is finite.

Use bcrypt cost 14+ if Argon2 isn't available. bcrypt is implemented in every language's standard library or a one-line dependency away. Cost factor 12 is the common default and adequate. Cost factor 14 is better — it quadruples the attacker's work for a 1.3× increase in your server's login-handling time. Measure your server's bcrypt verification latency at your target cost factor under realistic load, not at idle. A login that takes 800 ms during a traffic spike is a login that loses users. Find the number that keeps verification under 300 ms on your hardware and set the cost factor there.

Never use SHA-256, SHA-512, SHA-1, MD5, or any general-purpose hash for password storage. Not even with a salt. Not even "just for this internal tool." Not even "we'll migrate later." The salt stops rainbow table attacks. It does not slow down brute force. A salted SHA-256 hash is cracked at 20+ billion guesses per second on a single consumer GPU. The salt adds zero computational cost per guess — it's just an input prefix. Salted SHA-256 is only marginally better than unsalted SHA-256, and both are catastrophic.

If you're on NTLM, migrate. Yes, it's your corporate Active Directory. Yes, migrating is painful. But 100 billion guesses per second on a $2,000 GPU means that every password in your domain — including the 12-character ones with symbols — is vulnerable to an offline attack. The migration path is well-documented and has been since Windows Server 2016 introduced support for more modern credential providers. If your AD domain was compromised yesterday and you don't know it, your users' passwords are only as strong as NTLM allows them to be — which, as the numbers above make clear, is not very.

And all of this is wasted if users can set password123. Enforce a minimum length (10+ characters, don't require complexity rules that encourage P@ssw0rd1! — NIST dropped that recommendation in 2017 for a reason), check new passwords against the Have I Been Pwned API, and don't rotate passwords every 90 days. Forced rotation produces predictable patterns: Spring2026! becomes Summer2026!. The hash function can't save you from that.

Frequently Asked Questions

Methodology & Disclosure

Hash rate benchmarks are based on community hashcat benchmark data compiled June 2026 for RTX 4090 consumer GPUs and extrapolated to H100-class datacenter GPUs using a conservative 3× scaling factor for SHA-256/NTLM and 3× for bcrypt. Cloud GPU pricing uses Lambda Labs public on-demand H100 rates ($2.49/hr) — the pragmatic default for independent teams, as detailed in our GPU training cost analysis. Actual hash rates vary with driver version, thermal conditions, attack mode (dictionary vs. mask vs. brute force), and workload parallelism. bcrypt hash rates scale non-linearly with GPU count due to memory bandwidth contention — linear extrapolation is used here as a ceiling estimate; real multi-GPU bcrypt cracking is slower than the linear projection.

Keyspace exhaustion times assume the attacker must search on average 50% of the total keyspace to find a randomly chosen password. Human-chosen passwords — which comprise the vast majority of real-world credentials — are cracked much faster via wordlist, rule-based, and hybrid attacks that operate on dictionary words, common substitutions, and known breach corpuses. The brute-force numbers shown here apply to machine-generated random credentials: API keys, generated secrets, password-manager output. For human passwords, the most important defense is not length or character set but breach corpus checking (Have I Been Pwned API) at account creation time.

Disclosure: jslet is an independent research project. We are not sponsored by any hardware vendor, cloud provider, or security product company. The password crack time estimator was built to make the hash algorithm gap visible — to let anyone toggle between bcrypt, SHA-256, and NTLM and watch the crack time flip by seven orders of magnitude while the password stays the same. No affiliate links. No referral codes. No sponsored recommendations.

References & Further Reading

1. OWASP (2026). "Password Storage Cheat Sheet." Current recommendations for Argon2id, bcrypt, scrypt, and PBKDF2 parameter selection. owasp.org
2. NIST SP 800-63B (2024). "Digital Identity Guidelines — Authentication and Lifecycle Management." Current US federal password policy guidance: minimum 8 characters for user-chosen, 6 for randomly generated, no mandatory complexity rules, no periodic rotation. nist.gov
3. hashcat (2026). "Advanced Password Recovery — Benchmark Data." Community-maintained benchmark repository for GPU hash rates across algorithms and hardware configurations. hashcat.net
4. Provos, N. and Mazières, D. (1999). "A Future-Adaptable Password Scheme." Proceedings of the USENIX Annual Technical Conference. The original bcrypt paper. usenix.org
5. Biryukov, A., Dinu, D., and Khovratovich, D. (2016). "Argon2: The Memory-Hard Function for Password Hashing and Proof-of-Work." Password Hashing Competition winner documentation. github.com
6. Verizon (2024). "Data Breach Investigations Report (DBIR)." Annual analysis of real-world breach vectors and credential attack patterns. verizon.com
7. Have I Been Pwned (2026). "Pwned Passwords API." k-Anonymity-based password breach corpus for real-time credential checking without exposing the password. haveibeenpwned.com
8. NVIDIA (2026). "H100 Tensor Core GPU — Performance Specifications for Cryptographic Workloads." nvidia.com

📜 Copyright & Attribution

"Password Crack Times: The Algorithm Gap — Your Hash Function Matters More Than Your Password Length (2026)" — jslet Research, June 2026.
https://www.jslet.com/password-crack-time-real

📡 Enjoyed this? Your hash function matters more than your password length. The RSS feed delivers one counterintuitive security truth per week. No scare tactics. No vendor pitches. Just the math. RSS Feed → | More options →