In short: the honest answer to "how long to crack a password" is that it depends on three variables, and only one of them is under your control. The other two are the hashing algorithm the website chose and whether your password has ever leaked before. This post gives you the real math for each — and a tool on this site that runs it against your actual password instead of making you read someone else's chart.
Search for how long to crack password strings of a given length and you will get a dozen confident, mutually contradictory answers. Most "time to crack" articles hand you a colorful table and let you assume it applies to you. It usually does not. Below, every number is traceable to a published benchmark, the assumptions are stated in plain sight, and the places where the popular tables mislead people are called out directly.
How long to crack a password: the short answer
Password cracking time is the number of guesses an attacker must make divided by the number of guesses their hardware can make per second. That single formula drives every table you have ever seen on this topic.
The guess count is set by your password: a random password drawn from a set of C possible characters at length L has C^L possible values. The guess rate is set by the defender: a fast hash like MD5 lets one graphics card try hundreds of billions per second, while a deliberately slow hash like bcrypt cuts that to tens of thousands.
The bottom line: the same password can be "instant" or "millennia" depending entirely on a decision the website made, not one you made.
Here is what that looks like against a genuinely fast hash. These figures assume MD5 on a single NVIDIA RTX 4090, benchmarked by hashcat contributor Chick3nman at 164.1 GH/s (164.1 billion hashes per second) using hashcat v6.2.6.
| Character set | 8 chars | 10 chars | 12 chars | 14 chars | 16 chars |
|---|---|---|---|---|---|
| Digits only (10) | Instantly | Instantly | 6.1 seconds | 10 minutes | 17 hours |
| Lowercase (26) | 1.3 seconds | 14 minutes | 6.7 days | 12 years | 8,000 years |
| Upper + lower (52) | 5.4 minutes | 10 days | 76 years | 204,000 years | 552 million years |
| Alphanumeric (62) | 22 minutes | 59 days | 623 years | 2.4 million years | 9.2 billion years |
| Full ASCII (95) | 11 hours | 12 years | 104,000 years | 942 million years | 8.5 trillion years |
Computed as C^L ÷ 164.1 × 10⁹ hashes/sec. Assumes a truly random password and an unsalted MD5 hash already in the attacker's possession.
Notice how much faster the numbers grow going right than going down. That is the whole argument for length over complexity, and we will come back to it.
Want the same math run on your actual password rather than a category? The analyzer on the homepage estimates entropy and crack time client-side — nothing you type ever leaves your browser.
Why the hash algorithm matters more than your password
The hashing algorithm a website uses changes crack times by seven orders of magnitude — far more than any realistic change to your password. This is the single most important fact that static crack-time tables leave out.
When you create an account, a well-built site does not store your password. It stores a hash: a one-way scrambled version. MD5 and SHA-256 were designed to be fast, because their original job was verifying file integrity. bcrypt, scrypt, and Argon2 were designed to be deliberately, tunably slow, because their only job is to make guessing expensive.
Here is the gap, measured. The MD5, SHA-1 and SHA-256 rates are from Chick3nman's published hashcat v6.2.6 RTX 4090 benchmark. The bcrypt rate is Hive Systems' own measured figure for its 2026 table: 138,675 H/s aggregate against bcrypt work factor 10 across a rented fleet of sixteen RTX 5090s, which works out to roughly 8,700 H/s per card.
| Hash algorithm | Designed for | Guesses per second | Relative speed |
|---|---|---|---|
| MD5 | Fast checksums | 164.1 billion (1× RTX 4090) | Baseline |
| SHA-1 | Fast checksums | 50.9 billion (1× RTX 4090) | 3× slower |
| SHA-256 | Fast checksums | 22.7 billion (1× RTX 4090) | 7× slower |
| WPA2 (PBKDF2, 4,095 iterations) | Wi-Fi key derivation | 2.6 million (1× RTX 4090) | ~65,000× slower |
| bcrypt (work factor 10) | Password storage | ~8,700 (per RTX 5090) | ~19 million× slower |
Read that last row again. Against MD5, eight random lowercase letters last 1.3 seconds. Against bcrypt at work factor 10 on a single card, the same password would take roughly 280 days — about 24 million times longer, for a password you did not change at all.
The bottom line: you cannot pick the hash, so you have to assume some of your accounts use a bad one. That is an argument for length and uniqueness, not for despair.
Argon2id, the winner of the 2015 Password Hashing Competition, goes further by being memory-hard — it deliberately consumes large amounts of RAM per guess, which strips GPUs of their parallelism advantage. If you build software, that is what you should be reaching for. If you only use software, treat this section as your reason to stop worrying about which symbol to put in position four.
What Hive Systems' 2026 table actually says — and where it misleads
The most-cited crack-time chart on the internet is the Hive Systems Password Table, and its 2026 edition is genuinely good research — but readers routinely misapply it. Hive has published the table annually since 2020 and rebuilds it each year against hardware anyone can rent.
For 2026, Hive reports these headline figures:
- A randomly generated 8-character password using upper- and lowercase letters, numbers and symbols takes about 132 years to brute-force offline.
- Eight lowercase letters only: about two weeks.
- A common, reused, or dictionary-based password: instantly.
Their stated assumptions are a stolen bcrypt (cost 10) hash cracked offline on rented RTX 5090-class GPUs. Hive also notes something counterintuitive: their measured 138,675 H/s fleet of consumer RTX 5090s is faster than data-centre A100s at this task, because cracking is integer math rather than the floating-point work AI accelerators are tuned for. Eight A100s crack an 8-character upper-and-lowercase password in about 52 years; eight RTX 5090s do it in 23.
So where does it mislead? Three places, none of them Hive's fault:
- It is a maximum, not an expectation. The table shows the time to exhaust the entire keyspace. On average an attacker finds a random password in half that time, and finds a non-random one almost immediately.
- It assumes your password is random. Hive says this explicitly. Most people skim past it. If your password contains a word, a name, a year, or a keyboard pattern, you are not in that table at all.
- It models offline brute force only. That is a specific attack that requires the site to have been breached first. It is not the attack most people actually face.
Hive addressed point two directly in 2026 with a second chart for previously-stolen or dictionary-based passwords. Their measurement: on a single rented RTX 5090, a bcrypt-protected mixed-symbol password like o#mA24ft fell in about three seconds when the attacker tried predictable patterns before random strings. The same box cracked the literal password password from a rockyou.txt dictionary run in about the same time.
That is an eight-character password with uppercase, lowercase, digits and a symbol — the kind most corporate password policies would happily accept — dying in three seconds.
The number that actually matters: entropy
Password entropy is the number of bits of true randomness in a password, and it is the only measure that survives contact with a real attacker. A password's entropy is log₂(C^L) — the base-2 logarithm of its total possible values.
Entropy works where character-count rules fail because it measures unpredictability, not appearance. P@ssw0rd1 looks complex and has almost no entropy, because the substitutions are the first thing every cracking rule set tries. Twelve characters drawn randomly from a 62-character alphanumeric set carry about 71 bits.
| Password style | Approximate entropy | Realistic verdict |
|---|---|---|
| 8 chars, human-chosen with substitutions | Under 30 bits | Falls in seconds |
| 8 random alphanumeric characters | 48 bits | Weak against bcrypt, dead against MD5 |
| 4 random dictionary words (Diceware) | 52 bits | Borderline; ~6 hours vs MD5 |
| 12 random alphanumeric characters | 71 bits | Strong |
| 5 random dictionary words (Diceware) | 65 bits | Strong and memorable |
| 16 random full-ASCII characters | 105 bits | Overkill by any current measure |
Diceware passphrases use a 7,776-word list, so each word contributes log₂(7776) ≈ 12.9 bits. Against Hive's measured bcrypt fleet, a four-word passphrase holds for roughly 835 years and a five-word one for millions — but against MD5 on one RTX 4090, four words fall in about six hours and five words in about five years. Again: the hash decides.
For the full explanation of how entropy is calculated and why it beats character-count rules, see our guide to what password strength actually measures.
Why real attackers almost never brute force
Pure brute force is the attack of last resort, because credential stuffing is vastly cheaper and works more often. This is the part the crack-time tables cannot show you, and it is the reason a "million-year" password can still lose you an account tomorrow.
Verizon's 2025 Data Breach Investigations Report puts hard numbers on it:
- Compromised credentials were the initial access vector in 22% of the breaches Verizon reviewed — the single most common entry point.
- Analysing SSO provider logs, Verizon found credential stuffing accounted for a median 19% of all daily authentication attempts, rising to 25% at enterprise-sized companies and 12% at small businesses.
- From infostealer malware infection data, in the median case only 49% of a user's passwords across different services were distinct from each other.
That last statistic is the whole ballgame. The median person reuses roughly half their passwords. An attacker who obtains one working credential pair does not need to guess anything — they just replay it across hundreds of sites with a bot and wait for the 0.2–2% that hit.
Consider the economics. Exhausting the keyspace for eight random lowercase letters against bcrypt costs, by Hive Systems' estimate, over $3,000 in GPU rent and about two weeks of wall-clock time on their 16-card fleet — for exactly one password. A combo list of millions of already-valid credentials costs close to nothing and can be tested against dozens of sites in parallel. No rational attacker picks the first option.
The bottom line: your crack time is your floor, not your ceiling. Reuse sets it to zero regardless of what the calculator says. Our companion post on how hackers actually crack passwords covers dictionary attacks, rule-based mangling and rainbow tables in depth.
Online versus offline: two completely different clocks
Every crack-time number you have read assumes an offline attack, where the attacker holds the hash and can guess as fast as their hardware allows. Online attacks are thousands of times slower and are the only ones rate limiting can stop.
| Online attack | Offline attack | |
|---|---|---|
| What the attacker has | A login form | A stolen password hash |
| Guess rate | Limited by network and lockouts — often under 100/sec | Limited only by GPU — billions/sec for MD5 |
| Stopped by lockouts | Yes | No |
| Stopped by 2FA | Yes | Partially |
| Which one crack tables model | Never | Always |
This is why "the site locks me out after five failed attempts" is not the reassurance people think it is. Lockouts protect the live login form. Once a breach hands an attacker your hash, they copy it to their own hardware and the lockout is irrelevant — there is no server left to say no.
It is also why two-factor authentication changes the calculation more than any password improvement. A second factor makes a correctly guessed password insufficient on its own, which is precisely the failure mode credential stuffing exploits.
What crack time you should actually aim for
Target a password that survives offline brute force against a fast hash for longer than the data is worth — in practice, 12+ random characters or a 5-word passphrase — and then make sure it is used exactly once.
NIST's SP 800-63B-4 digital identity guidelines, finalised in 2025, made four changes that follow directly from everything above:
- A 15-character minimum for single-factor passwords. Where a password is the only thing standing between an attacker and the account, verifiers must require at least 15 characters. The lower 8-character floor applies only when the password is one factor among several.
- No composition rules. Organisations are told not to require a mix of uppercase, symbols and digits — those rules reliably produce
Password1!rather than genuine entropy. - No forced periodic rotation. Passwords should only be changed on evidence of compromise, because rotation drives predictable increments.
- Mandatory blocklist screening against known-breached passwords.
That last requirement is NIST conceding the same point this article has been making: a password's membership in a breach list matters more than its length. We cover the full standard in our breakdown of the NIST password guidelines.
Practical translation:
- Length beats complexity. Twelve random alphanumeric characters (71 bits) beat eight full-ASCII characters (52 bits) comfortably, and are easier to type.
- Uniqueness beats both. A 40-bit unique password is safer in practice than a 100-bit one you reused, because reuse converts a brute-force problem into a lookup.
- Let software handle it. Generating and remembering 100+ unique high-entropy passwords is not a human-scale task. A password manager is the only realistic delivery mechanism for the advice above.
- Add a second factor everywhere it is offered. It defends the attack that is actually happening.
- Watch the exit. Passkeys are already replacing passwords on major platforms, and they remove the crack-time question entirely — there is no shared secret on the server to steal.
Test your own password instead of reading a table
The problem with every static crack-time table, including the ones in this article, is that it categorises your password rather than evaluating it. A table cannot tell that your 14-character password is three dictionary words and a birth year, so it cannot tell you how long to crack a password you actually use.
The analyzer on this site's homepage runs the actual entropy calculation on the password you type, checks it against a common-password list, flags predictable patterns, and reports estimated crack times across attack scenarios. Everything happens in your browser — the password is never transmitted, logged or stored.
Try this: enter a password you consider strong, then enter a random 12-character one from the Generate tab and compare. The gap is usually much larger than people expect, and it is a more useful number than any row in any chart, because it is about your password rather than a category your password might belong to.
Related reading
- How Hackers Actually Crack Passwords — dictionary attacks, rule-based mangling and rainbow tables explained
- What Is Password Strength? — how entropy is calculated and why character-count rules fail
- NIST Password Guidelines Explained — what SP 800-63B-4 requires and why rotation was dropped
- Password Managers: A Complete Guide — generating and storing unique high-entropy credentials
- Passkeys vs Passwords — the authentication model that removes crack time from the equation
- Two-Factor Authentication Explained — why a second factor beats a longer password
What to do next
Three concrete steps, in order of impact:
- Check your passwords for reuse. This is the highest-value action on the list, because reuse defeats every other defence. Most password managers audit this automatically.
- Replace anything under 12 characters on accounts that matter — email, banking, and any account that can reset the others. Use the password generator on this site or your manager's built-in one.
- Turn on two-factor authentication everywhere it is offered, prioritising your primary email account.
Then run your most important password through the analyzer and see where it lands. If the number surprises you, that is the tool doing its job — and unlike the tables, it is answering the question about your password rather than about a category.
