Are Your Passwords in the Green?
Every year we ask the same simple question - how long would it take a hacker to crack your password - and every year the answer gets a little shorter. Not because your password changed, but because the computers doing the work keep getting faster, cheaper to rent, and easier to configure.
The 2026 Hive Systems Password Table is here.
Prefer a quick video breakdown instead?
Tune in later this month for our Hive Live episode breakdown!
This is the long version of how we built the table, which assumptions we made, what changed this year, and the two questions we got more than any other over the last year: what AI does to your password, and what quantum computing is about to do to encryption.
Since 2020 we've published an annual chart of how long offline guessing takes against your passwords. The colors are the public face, but the work underneath is heavily researched and based on actual benchmarks, breach data, and hardware that we (or anyone) can actually rent.
Got a question or comment? Leave a comment below, or message us on social media!
“So how'd you make the table?”
How It Started vs. How It's Going
In 2020, we first shared our Password Table, based on data from www.howsecureismypassword.net (now run over by the folks at security.org) and assembled by Mike Halsey, Microsoft MVP, which looked at the relative strength of a hashed password against a cracking attempt, based on the password’s length, complexity, hashing algorithm used by the victim, and the hardware used by the attacker.
2020 hardware: 1 x RTX 2080 | 2020 password hash: MD5
In 2022, we dove in deeper on the data and hardware used to create a more accurate picture. The data in that table was based on how long it would take a consumer-budget hacker to crack your password hash using a desktop computer with a top-tier graphics card and then how long an organized-crime-budget hacker would take leveraging cloud computing resources. We looked at big name providers like Amazon AWS and Microsoft Azure but also the growing non-corporate options where you can rent a person’s computer at cost per hour.
2022 hardware: 8 x A100 | 2022 password hash: MD5
In 2023, we updated our cracking hardware to the latest and greatest, including that of the internet darling ChatGPT, and opted for a more realistic set of special characters in our testing since most websites only accept these ^*%$!&@# and so we dropped the rest. That only impacted the right-most column of the table
2023 hardware: 12 x RTX 4090 | 2023 password hash: MD5
In 2024, we looked at what hashing (if any) had been observed in password breaches over the years and based on recent data and trends, moved from assuming MD5 to assuming bcrypt. For bcrypt, we also set it to 32 iterations. We stuck with 12x RTX 4090s because that still appears to be the best consumer accessible hardware configuration that won’t block you from running tools used for brute forcing passwords. We also started offering the Password Table in multiple languages!
2024 hardware: 12 x RTX 4090 | 2024 password hash: bcrypt set to a work order of 5 (i.e. 32 iterations of hashing)
In 2025, we moved from the hashcat default bcrypt settings to the bcrypt strength levels people seem to use most in the wild. NVIDIA finally released a new consumer card, the RTX 5090, and to simulate a fairly successful hacker we once again assumed not one but twelve of them.
2025 hardware: 12 x RTX 5090 | 2025 password hash: bcrypt set to a work order of 10 (i.e. 1024 iterations of hashing)
This year, we changed how we think about the rig itself. The headline table no longer assumes a single twelve-GPU chassis, because you can't really rent one. We'll get into why - and why AI is quietly part of that story - in a moment. But first, the piece everyone asks about.
2026 hardware : 16 x RTX 5090 | 2026 password hash: bcrypt set to a work order of 10 (i.e. 1024 iterations of hashing)
"Ok so where did you start?"
Let’s get a couple of definitions out of the way first. the context of passwords, a “hash” is a scrambled version of text that is reproducible if you know what hash software was used. In other words, if your friend hashes the word “password” using MD5 hashing, the output hash will be 5f4dcc3b5aa765d61d8327deb882cf99. Now if you hash the word “password” using MD5 hashing , you’ll also get 5f4dcc3b5aa765d61d8327deb882cf99! You and your friend both secretly know the word “password” is the secret code, but anyone else watching you just sees 5f4dcc3b5aa765d61d8327deb882cf99. Passwords are stored on servers as hashes like this instead of in plain text, so that if someone steals the database, all they see are the hashes and not the passwords that made them.
You can't do the reverse. A hash like 5f4dcc3b5aa765d61d8327deb882cf99 can't be computed back into "password." Hashing is a one-way street by design. So the way hackers solve that problem is by "cracking" instead. Cracking means making a list of all the character combinations on your keyboard, hashing every one, and then looking for matches between your list and a breached database of password hashes. You can do that with any computer, but it's much faster if you accelerate it with a powerful graphics card.
Graphics cards are those circuit boards that stick out of your computer's bigger green circuit board. Among other things, they carry a GPU - the shiny square tile that maybe says NVIDIA or AMD on it. GPU stands for graphical processing unit. They were built to make pictures load faster on your screen (or mine cryptocurrency, if that's your thing), and it turns out they're also great at calculating hashes. A popular tool for this is Hashcat., which supports bcrypt plus thousands of other hash functions and logs how fast it churned through them.
When you shop for a graphics card or cloud GPU, you're given "calculations per second," usually in floating point operations per second (FLOPS). But FLOPS don't account for the quirks of hashing algorithms, password character composition, or the hardware around the card. Fortunately, hashcat made it easy for password-recovery experts to test their hardware on real hashing exercises and share the results. That ever-growing dataset of observed performance is what we mean by "benchmarks."
"Hold on - don't websites lock you out after a few wrong guesses?"
This is the single most common question we get about this table, so let's clear it up right away: yes but it doesn't matter.
The "five strikes and you're locked out" rule only guards the login form on a live website. It does absolutely nothing once your hashed password is sitting in a stolen database dump on the hacker’s own machine. At that point there's no lockout, no rate limit, no "suspicious login" email, and no one to slow them down. They copy the hashes onto their own hardware and guess billions of times per second, for as long as they like, completely offline.
So an attacker never has to beat your login page or your favorite website’s - they just have to wait. One breach hands them the hashes, and after that it's a stopwatch. Grab it now, break it later. Every number in this table assumes exactly that: your password is already sitting in someone's hands as a hash, and time is the only thing between them and getting your real password. It's the same move that makes quantum computing so dangerous, which we'll get to a little later.
"So how do you decide what actually goes in the table each year?"
There are two main dials we can adjust.
The hardware (i.e. GPU) doing the cracking
The hash that scrambled your password before it was stolen
Dial one: the hardware
For years the answer relatively straight forward and limited to the technological knowhow of the average hacker (and us for that matter). However this year some things change.
When we went shopping for our usual twelve-GPU chassis, they basically weren't there. A Vast marketplace poll recently turned up roughly 20 rentable 8x RTX 5090 listings and zero rentable 12x RTX 5090 offers at the same snapshot. So we did what an actual motivated attacker would do when the datacenter-scale box isn't for rent: we composed one out of what exists. We measured a 2x 8x RTX 5090 Vast fleet - two separate cloud rentals with the keyspace partitioned between them - running at 138,675 H/s aggregate against bcrypt cost 10. That's about 24% faster than our 2025 twelve-GPU reference (111,490 H/s), and it reflects what someone can rent today. If you’re wondering why we didn’t rent data center level hardware, we’ll touch on that further down.
AI is also part of this story - specifically, it's what made assembling that fleet easy. Stitching two rented eight-GPU hosts together used to be incredibly technical and a barrier to entry for most people - API loops, SSH setup, mask partitioning, babysitting jobs across machines. AI-assisted scripting flattens all of that. The barrier to standing up a bigger, meaner cracking rig is lower than it's ever been, which is exactly why we stopped assuming the nice single chassis package and started assuming a fleet.
What didn't change: AI didn't make each GPU any faster at bcrypt since per-GPU hash rate is the per-GPU hash rate. AI did lower the operational barrier to renting and orchestrating more hardware. For the record, beyond the main grid we also captured the dictionary-and-reuse variation (single RTX 5090, roughly 3 seconds on representative targets) and logged a 12x PRO 6000 single-stack run at 116,280 H/s for some appendix comparisons only.
Dial two: the hash
The second dial is whatever scrambled your password before it was stolen, and we don't guess at it - we look at what real breaches used. We reviewed password breaches from 2007 to today, as catalogued by HaveIBeenPwned, and sorted them by hash type.
The count of passwords breached, regardless of source, colored by hash type. Data from www.haveibeenpwned.com
Raw password counts are noisy. Take 2025: a single year with 2.6 billion breached passwords, almost all of them from dumps where the hash type isn't even known. One event like that swamps the whole chart, so the raw tally tells you little about what a typical site uses. So we count it another way too - whole breached datasets instead of individual passwords - which stops one giant dump from drowning out everything else.
The count of whole password datasets breached at businesses and organizations, colored by hash type. Data from www.haveibeenpwned.com
Counted this way, the picture is clear: MD5 ruled for years, then bcrypt took the lead. Password managers like LastPass, 1Password, and Bitwarden use PBKDF2 salted with SHA-256, and NIST recommends PBKDF2 SHA-256 as well. But what people are choosing looks different - breached hashes from Dropbox, Ethereum, MyFitnessPal, and DataCamp all used bcrypt. It may also be the tougher target, in terms of the resources needed to crack it so bcrypt is our chosen hash.
But bcrypt isn’t one size fits all and lets you set a "work factor" that you can crank up as cracking hardware improves. The hashcat default (a factor of 5) doesn't reflect the real world, so we checked the out-of-the-box bcrypt settings in popular stacks:
OpenBSD - bcrypt has been the default password scheme since version 2.1. Work order of 10
Laravel - uses bcrypt as its default hashing algorithm. Work order of 12
PHP - the password_hash() function uses bcrypt by default. Work order of 12
Auth0 - uses bcrypt for password hashing. Work order of 10
SuperTokens - uses bcrypt by default. Work order of 11
For the second year running, we set bcrypt to a work order of 10 - a realistic worst case based on those defaults and other research across common apps and libraries. We kept it steady on purpose: change both dials at once and you can't tell what moved the numbers year over year of course, but the data shows that a work order of 10 is still the chosen balance of speed and security most developers (and AI) are still choosing.
What about salting? Like Argon2id and PBKDF2, bcrypt automatically salts passwords, so no extra steps or salt bases are needed when you implement it - other than setting the work factor.
So when Put both dials together and you have the table: a capable offline attacker on a measured 2x 8x RTX 5090 fleet, cracking bcrypt at cost 10. That's the 2026 Hive Systems Password Table.
"So how much difference does GPU power actually make?"
Assuming the 8-character bare-minimum password NIST recommends, and a strong hash implementation (bcrypt work factor 10), it looks like this:
Max time required to crack randomly generated 8-character bcrypt work factor 10 password hashes of various complexity on different hardware.
The consumer cards beat the data-center hardware, which catches most people off guard. Eight NVIDIA A100s - the expensive silicon built for AI workloads - crack an 8-character password of upper- and lowercase letters in about 52 years. Eight RTX 5090 gaming cards do it in 23, more than twice as fast. Cracking runs on plain integer math, not the heavy floating-point work data-center accelerators are tuned for, so paying enterprise prices buys no speed here. It's why our fleet is built from 5090s, not A100s.
So even with the benefit of the doubt - bcrypt at a work factor 10 - a motivated renter with cloud cash can exhaust short random keyspaces faster on a fleet than on a single GPU. But fully brute-forcing eight random lowercase letters still costs on the order of $3,000+ in GPU rent (roughly two weeks of wall-clock time on our 2x 8x fleet at recent Vast pricing). Eight-digit PINs stay in the ~$2 class. For most budgets, on strong random passwords, a few hundred years is still great - especially at bcrypt's price tag of $0.00. But remember, that assumes the password was randomly generated.
| Stack (bcrypt cost 10) | Approx. burn rate | Time to exhaust 8 random lowercase |
|---|---|---|
| 1x RTX 5090 (Vast) | ~$0.52/hr | ~9 months wall-clock |
| 1x 8x RTX 5090 | ~$4.27/hr | ~5 weeks wall-clock |
| 2x 8x fleet (2026 table) | ~$8.54/hr | ~2 weeks wall-clock, ~$3,400 GPU rent |
Bigger fleets burn faster, not cheaper. At linear cloud pricing, the total dollars to exhaust the same random keyspace stay roughly flat. You're buying speed, not a discount.
"Wait - is my password getting weaker every year?"
Not exactly. It’s the hardware hackers are using is getting more powerful. The same power that makes your phone and laptops faster also helps the bad guys.😱
Every year we rerun this table on the best rig a motivated attacker can actually rent, and every year that rig gets faster and cheaper to point. This year's fleet clocks about 24% faster than last year's, and that tracks with a trend we've watched for a while now: crack times have been falling by roughly a fifth to a quarter, year over year.
For a single cell, take an 8-character password with the full mix - numbers, upper, lower, and symbols:
2024: 225 years
2025: 164 years
2026: 132 years
Same password and hash every year. And for our most diligent readers at home, our official 2024 table ran at bcrypt work order of 5, so we reran the 2024 table at a work order of 10 to line it up with 2025 and 2026. That leaves the hardware as the only thing changing from frame to frame - and this year, AI-assisted scripting made assembling a faster rig easier than it's ever been. It's the whole reason we rebuild this every year - the world keeps moving.
Quick note on the math, because someone always asks: "24% faster hardware" and "20% shorter crack times" are the same jump described two ways. A rig that's 24% faster finishes in about 80% of the time, so times drop by about a fifth. It’s one gain but with two different framings but we’re not stacking them.
"Ok but isn't AI about to crack everything anyway?"
This is the hot topic this year but I guess the saying goes there’s two sides to every coin:
Side one: AI is exceptionally good at hacking. The clearest proof is a model so capable that Anthropic declined to release it to the public. Announced in April 2026 as "Mythos Preview" and handed to only a few people at about a dozen major tech and security companies - the likes of Amazon, Apple, Microsoft, Google, Nvidia and others - under a program called Project Glasswing, the model was flagged by red-team testers as unusually strong at computer-security tasks, and by Anthropic's own account better than humans at some of them. Anthropic said Mythos had already turned up thousands of high-severity vulnerabilities, with examples in every major operating system and browser, and that with little oversight it pinpointed a critical bug that had sat undiscovered in a system for 27 years and suggested how to exploit it. The former head of the UK's National Cyber Security Centre put it bluntly to the BBC: "it's just a really good hacker."
A few caveats, though: Not every independent expert has been able to test it (including us - rude!), some of this is Anthropic talking up its own product, and the UK's AI Safety Institute has said the real danger is to poorly defended systems rather than well-secured ones. And this wasn’t just a theoretical exercise since Anthropic separately disclosed a state-sponsored espionage campaign in late 2025 in which an AI agent (a different tool, not Mythos) carried out the large majority of an actual attack across roughly 30 targets, firing off requests at a pace no human crew could match.
So yes - AI is a real force multiplier for the thinking parts of an attack: finding the way in, writing the exploit, tailoring the phishing lure, even orchestrating a rented cracking fleet like the one we built for this very table.
Side two: and yet that same class of AI is useless at brute-forcing a strong password. A model like Mythos is dangerous precisely because hacking is mostly a thinking problem - spot the flaw, reason out the exploit, chain the steps together. Brute-forcing a bcrypt hash is not a thinking problem. It's a raw-throughput problem (more powah 💪), bounded entirely by how many hashes per second your hardware can grind and by how deliberately slow bcrypt is. All the reasoning in the world doesn't move that needle.
The cleanest proof showed up in April 2026, when researchers benchmarked a $30,000 AI accelerator (NVIDIA's H200) against a gaming card (the RTX 5090) at password cracking. The expensive AI silicon was, across almost everything, no better - and often worse - than the consumer GPU. AI hardware is built for the tensor math that trains models, which is close to the opposite of the plain 32-bit integer work that hash cracking needs. Point an LLM itself at the job and it does even worse: in one study, tested models scored under 1.5% accuracy, far below old-fashioned rule-based cracking.
Put the two halves together: the most dangerous hacking AI ever built still can't shortcut a slow, salted bcrypt hash. But as we called out earlier, AI lowered the barrier to assembling a bigger cracking rig - which is exactly why this year's table is faster - but it did nothing to make each GPU any better at bcrypt.t.
And what if hackers got a hold of the kind of massive compute used to train frontier models? We couldn't rent 10,000 or 20,000 A100s to benchmark bcrypt at that scale, and spec-sheet FLOPS and real bcrypt hash rates aren't the same unit anyway. But even at those scales, bcrypt still does it’s job. We keep those extreme scenarios as thought experiments, separate from what we measured here!
"Ok. Asking for a friend: what if my password's been stolen before, uses real words, or I reuse it?"
Then the table above doesn't apply to you but not in a cool or get-out-of-jail-free kind of way.
Our table models a hacker working from scratch, in a black box, to show the worst-case maximum time. Real attackers don't start from scratch. They start with rainbow tables, dictionary attacks, and hashes from previous breaches. If your password was in another breach, contains dictionary words, or gets reused across sites, your personal table looks like this:
Password table if your password has been previously stolen, uses dictionary words, or if you reuse it between websites.
New for 2026: we timed this scenario on real hardware. On a single rented RTX 5090, a bcrypt-protected password like the mixed-symbols example in our table (o#mA24ft) cracked in about three seconds when the attacker tried predictable guesses first - not every possible random string. On the same box, a common breach-list run (rockyou.txt with hashcat rules) against password cracked in about the same time.
The main table still shows maximum time against random brute force as this is the BEST case scenario for you and your password. But this purple monster is the one to remember when you make poor password choices which, statistically, is most of us 🫠
"Ok but what about quantum computers? Isn't that the real doomsday?"
Quantum computing is a real threat and it doesn't change this year's (or next year’s) table, but quantum computers don't break all encryption equally. There are two famous quantum algorithms with some key differences (nerdy stuff ahead 🤓):
Shor's algorithm is the scary one. It gives an exponential speedup at the specific math that public-key cryptography relies on - the factoring and discrete-log problems behind RSA, elliptic-curve (ECC), and Diffie-Hellman. That's the cryptography protecting the padlock in your browser, your VPN tunnels, and digital signatures. A big enough quantum computer running Shor's would gut it.
Grover's algorithm is the mild one. Against symmetric encryption (like AES) and hash functions (like bcrypt), the best quantum trick only gives a square-root speedup - it roughly halves the effective strength. Halving sounds bad until you realize the fix is trivial: use a bigger key or a stronger hash and you're back to comfortable. AES-256 stays fine. Strong password hashing stays fine.
Which means the upshot for passwords is anticlimactic: quantum computing is coming for public-key encryption, not for your bcrypt-hashed password. A cryptographically relevant quantum computer would be a nightmare for the key exchange that sets up an encrypted connection. It would not hand anyone a shortcut through a slow, memory-hard password hash the way it hands them a shortcut through RSA. So this doesn't rewrite the 2026 table. Bcrypt is stubborn in exactly the way quantum is bad at which is why it’s considered a “quantum resistent” encryption method.
How close is it? Closer than it was, and moving. Google's Willow chip (late 2024) demonstrated error correction that improves as you add qubits - the milestone the whole field had been chasing. IBM has laid out a public roadmap to a large fault-tolerant machine by around 2029. And in May 2025, Google researchers slashed the estimated cost of breaking RSA-2048 to under a million noisy qubits - a roughly 20x drop from their own 2019 estimate of 20 million. Nobody has a machine near that today, and expert timelines for a truly code-breaking quantum computer still range wildly across the next decade-plus. But the trend line keeps pulling the horizon closer, not pushing it away.
So why care now? Because of a move you've already seen in this post - grab it now, break it later - only this time aimed at encryption instead of passwords. It's called "harvest now, decrypt later," and the harvesting is happening today. Adversaries record and store encrypted traffic and files they can't read yet, betting they'll be able to decrypt the whole archive once a capable quantum computer arrives. Anything that has to stay secret for years - health records, government secrets, financial data, intellectual property - is effectively at risk the moment it's captured, long before “Q-Day” arrives.
The good news is market leaders and regulators are already moving. In August 2024, NIST finalized its first post-quantum cryptography standards (ML-KEM, formerly Kyber, for key exchange, plus ML-DSA and SLH-DSA for signatures), and a 2026 executive order set federal deadlines around 2030-2031 to migrate off the vulnerable algorithms. The migration is a big lift, but it's underway.
The takeaway for this table: your long, random, bcrypt-hashed password is not the thing quantum breaks. But the encryption wrapped around huge swaths of the internet is on a clock - and unlike a slow cracking rig, that's not a problem you can out-wait.
“Ok but what’s the deal with these huge numbers?”
Different countries, regions, and schools of thought abbreviate big numbers differently. The Password Table uses these:
| Table Abbreviation | Word | e.g. (10^n zeros) |
|---|---|---|
| k | thousand | 1,000.00 |
| m | million | 1,000,000.00 |
| bn | billion | 1,000,000,000.00 |
| tn | trillion | 1,000,000,000,000.00 |
| qd | quadrillion | 1,000,000,000,000,000.00 |
| qn | quintillion | 1,000,000,000,000,000,000.00 |
| sx | sextillion | 1,000,000,000,000,000,000,000.00 |
| spt | septillion | 1,000,000,000,000,000,000,000,000.00 |
| oct | octillion | 1,000,000,000,000,000,000,000,000,000.00 |
| non | nonillion | 1,000,000,000,000,000,000,000,000,000,000.00 |
| dec | decillion | 1,000,000,000,000,000,000,000,000,000,000,000.00 |
Limitations of our work
Cracking passwords this way assumes the attacker has already acquired a hash of one or more passwords, like those found in breaches on HaveIBeenPwned.
The implied attack assumes MFA isn't used or has been bypassed. If you can download the encrypted database - which is exactly what happens with most stolen password databases - you don't need to deal with MFA (or those pesky login lockouts) on any of your attempts afterward. This is the offline reality we walked through up top: once the hashes are in hand, the login page's defenses are irrelevant.
These metrics assume passwords are randomly generated. Non-random passwords are much easier and faster to crack, because humans are predictable, so the times in these tables are a best-case reference point. Non-random passwords fall much faster.
These metrics assume a password that hasn't been part of a past breach. Attackers try all common and breached passwords before bothering to crack new ones.
Hashing a pile of candidate passwords is only step one of "cracking." Step two is basically a ctrl+F for matches between your hashed candidates and the breached hash set. We assume that lookup takes a trivial amount of extra time and compute.
The breaches that reach HaveIBeenPwned's hall of shame may not represent every breach that happens quietly. There's likely selection and survival bias filtering some out before they show up. LastPass, for instance, had a big scary breach but still hasn't appeared there, because the actual data hasn't been shared publicly. It may also be that when people use strong enough encryption, nobody bothers sharing or selling the dataset, because nobody will buy it or bother cracking it.
We don't include every QWERTY symbol. The symbols most commonly accepted across sites, and generated by most password generators, are limited to ^*%$!&@#, so that's what we include. That choice only affects the right-most column of our tables.
| Encoding | Alias | Character Range | Characters |
|---|---|---|---|
| ASCII | Lowercase | a-z | 26 |
| ASCII | Uppercase | A-Z | 26 |
| ASCII | Numbers | 0-9 | 10 |
| ASCII | Symbols A | ^*%$!&@# | 8 |
Frequently asked questions (FAQs)
-
It depends on length, complexity, and whether the password is random. According to the 2026 Hive Systems Password Table, a randomly generated 8-character password using numbers, upper- and lowercase letters, and symbols would take a hacker about 132 years to brute-force offline. Cut it to 8 lowercase letters and it drops to about two weeks; a common, reused, or dictionary-based password can fall instantly. These times assume an attacker cracking a stolen bcrypt (cost 10) hash offline on rented RTX 5090-class GPUs.
-
The Hive Systems Password Table is a free annual chart, published since 2020, that shows how long it would take a hacker to brute-force a password based on its length and complexity. Every year we rebuild it using real benchmarks on the best hardware a motivated attacker can actually rent, and the password-hashing method most commonly seen in real-world breaches. You can view and download it at hivesystems.com/password.
-
Longer is almost always better than more complex, because length is the single biggest factor in how hard a password is to crack. Each additional character multiplies the number of possible combinations far more than adding another symbol type does, so a long passphrase beats a short, clever-looking one every time. Aim well past the 8-character bare minimum, and let a password manager generate something long and random.
-
Yes. Account lockouts only protect the login form on the live website - they do nothing once your password's hash has been stolen in a data breach. At that point the attacker copies the hash onto their own hardware and guesses offline, billions of times per second, with no lockout, no rate limit, and no alert. That offline scenario is exactly what our table measures.
-
Not in the way most people fear. AI is extraordinarily good at the thinking parts of hacking - finding software vulnerabilities and writing exploits - but brute-forcing a strong hash like bcrypt is a raw-hardware problem that AI doesn't speed up. In 2026 benchmarks, a $30,000 AI accelerator was no better, and sometimes worse, at password cracking than a consumer gaming GPU. Where AI does matter is by lowering the barrier to assembling bigger cracking rigs, which is part of why crack times keep falling each year.
-
Not the strong, hashed ones - at least not the way they will break other encryption. Quantum computers threaten public-key encryption like RSA and elliptic-curve cryptography (through Shor's algorithm), but they only modestly weaken password hashes and symmetric encryption (through Grover's algorithm), which a longer key or stronger hash easily offsets. Your bcrypt-hashed password is relatively quantum-resistant; the bigger quantum risk is to the encryption protecting internet traffic, not your password itself.
-
Harvest now, decrypt later is a strategy where attackers steal encrypted data today and store it, planning to decrypt it later once quantum computers are powerful enough to break today's encryption. It matters right now because anything that has to stay secret for years - medical, financial, or government records - is effectively already at risk the moment it's captured. It's the same "grab it now, break it later" logic behind cracking stolen password hashes offline.
-
The 2026 table assumes an attacker cracking bcrypt (work factor 10) hashes offline using a rented cloud GPU fleet - specifically two 8x RTX 5090 setups running at a measured 138,675 hashes per second combined. We use bcrypt because it's the hashing method most commonly found in real-world breaches, and we moved to a rented multi-GPU fleet because single 12-GPU boxes are now hard to rent while composing a fleet from smaller ones has become easy.
-
Yes - crack times have been falling by roughly a fifth to a quarter each year, not because passwords change but because the hardware pointed at them keeps getting faster and cheaper to rent. A randomly generated 8-character password with the full character mix took about 225 years to crack in our 2024 table, 164 years in 2025, and 132 years in 2026. The defense is the same as always: longer, random, unique passwords stay far ahead of the curve.
Acknowledgements
Thank you to everyone who read, shared, and challenged last year's table in comments, email, Reddit, and YouTube. That feedback steers each year's refresh.
Thank you to the multiple people who helped translate the Password Table into other languages. If you’d like to see the Password Table in your language, please contact us.
Thank you to the over 6 million of you who have seen, read, and shared our work!
References
Hashes per second (H/s) benchmarks were either generated by Hive Systems using hashcat on local hardware or cloud rentals.
We obtained GPU hardware specs from the manufacturer or www.techpowerup.com/gpu-specs.
Want to see the Password Table from past years?
Cite this research
Report ID: HS-PWD-2026-001
@misc{neskey2026passwords,
title={Are your passwords in the green},
author={Neskey, Corey},
year={2026},
month={7},
day={14},
url={https://www.hivesystems.com/blog/are-your-passwords-in-the-green},
publisher={Hive Systems},
note={Technical report HS-PWD-2026-001}
}
Share or leave a comment
Need a high res version or in another language?
Another great shareable infographic:
The Cyber Attack Perception Problem
