Are Your Passwords in the Green?
It’s here! The 2024 update to the Hive Systems Password Table that’s been shown and written about in the news, published by universities, and shared by thousands of companies across the globe. How did we make this table and what’s behind the math? Read on!
Not a reader? Check out our video breakdown of this year’s table instead!
Looking at Passwords in 2024
Since 2020, we’ve conducted a lot of research to develop and present the Hive Systems Password Table which shows the time it takes a hacker to brute force your password. But for those of you that want to learn more about how we make the table - then you’ve come to the right place! A lot more goes into it than just pretty colors, and while the data fits nicely into the table above, things aren’t as as simple as they look. So let’s talk through the data, our assumptions, and oh, you’re going to see a LOT of variations of the password table (including one that’s all purple 😱).
Got a question or comment? Leave a comment below, or message us on social media (X/Twitter, LinkedIn, Instagram, Facebook, Reddit)
Heard about the LastPass breach? Check out the variations of our Password Table where we dive deeper into what happened and see how you may be impacted.
“So how'd you make the table?”
We’re feeling a little nostalgic so let’s start by looking back at how the Password Table has changed over the years (including for 2024):
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 took a look 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 now offer the Password Table in multiple languages!
2024 hardware: 12 x RTX 4090 | 2024 password hash: bcrypt
Now that we’ve got that out of the way, let’s talk about “hashing.” In 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 in servers as hashes like this instead of in plain text like “password.” That way, if someone steals the database all they can see are these hashes but not the password that made them.
You can’t do the reverse. A hash digest like 5f4dcc3b5aa765d61d8327deb882cf99 can’t be computed to produce the word “password” that was used to make it. Hashing software is a one-way-street by design. The way that hackers solve this problem is by “cracking” the passwords instead. In this context, “cracking” means making a list of all combinations of characters on your keyboard and then hashing them. Then you look for matches between the list and a breached database of password hashes. You can do that with any computer, but it is much faster if you accelerate the process 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, this special circuit board has a GPU on it. A GPU is the shiny square tile on your graphics card that maybe says NVIDIA or AMD on it. GPU stands for graphical processing unit – they were built to make pictures load faster on your computer screen (and to play great video games). As it turns out, they’re also great at calculating hashes too. A popular application for hashing is called Hashcat. Hashcat includes hashing software like bcrypt and allows you to try not just bcrypt but thousands of others and see how fast it was able to do so. We usually say “hash function” instead of “hash software.”
When shopping for a graphics card or cloud GPU, you’re given “calculations per second,” usually in “floating point operations per second” (FLOPS). The FLOPS measure doesn’t take into account the unique properties of hashing algorithms, password character composition, and the hardware “around” the graphics card like your motherboard, CPU, and RAM. Fortunately, hashcat made it easy for password recovery experts to automate testing their hardware on real hashing exercises and then log the results to share. The result is an ever-growing dataset of observed hashing performance using various hardware and hashing approaches called “benchmarks”.
“So how much different is that in terms of time?”
Assuming the 8-character password recommendation from NIST is used:
So even with benefit-of-the-doubt bcrypt, we’re still talkin’ 5 days tops if you have lots of cash. But for most budgets, up to 12 years seems decent if you’re also changing the password and it’s randomly generated.
“So how did you pick just one of these to be the 2024 Password Table’?”
We reviewed password data breaches from 2007 to present, reported on HaveIBeenPwned.
In terms of the number of credentials breached, regardless of source this is what it looks like as of April 2024:
MD5 reigned supreme for several years but bcrypt was in the lead in 2020, 2021, 2023 and again so far in 2024.
Password storage solutions like LastPass, 1Password, and Bitwarden use the hashing approach called PBKDF2 salted with a strong hash alternative to MD5, called SHA-256. Even NIST recommends PBKDF2 SHA-256. But as we’ve seen, things look different “in the wild.” Breached password hashes from Dropbox, Ethereum, MyFitnessPal and DataCamp all used bcrypt instead of a key derivation function like PBKDF2. Bcrypt also seems to be the more secure option in terms of resources required to crack it. As a result, the 2024 Hive Systems Password Table is based on the power of the 12 RTX 4090 GPUs against bcrypt.
“But wait - what’s up with the times going up from last year?”
Good question and great memory! In year's past the password hash we used was MD5. As we just noted above 👆, we’re not seeing MD5 as much in breaches any, which likely means websites and companies are using it less (a good thing!) As such, we’ve updated this year’s Password Table to bcrypt which is a more robust password hash so it's "pushed the purple" back up - but that likely won't last as computing power increases in the coming years.
If you’re technically savvy and love encryption like us, this year’s Password Table is calculated on a work factor of 32 for bcrypt. And while you may say “that’s not the industry best practice/ not recommended by OWASP” - time and time again, we see implementations in the wild and in the breach data that point to insecure configurations and implementations of password hashes and this year is not different! If this changes over the next year, we’ll update the work factor!
“Ok got it, but what if my password has been previously stolen, uses simple words, or I reuse it between sites?”
Our password table focuses on the idea that the hacker is working in a “black box” situation and is having to start from scratch to crack your hash in order to show the “worst case” or “maximum time required.” Most hackers will prioritize which words and strings of characters they’ll work on first through the use of rainbow tables, dictionary attacks, and previously stolen hashes. If your password was part of another breach or uses dictionary words then your password table looks like this:
“What about that xkcd comic on passphrases?”
First of all, can you believe that comic was from 13 years ago 🧓. Our password table graphic doesn’t go up to the number of characters in the xkcd example (25) simply because you have to draw a line somewhere with the size of an image. For the stats on their password ‘correcthorsebatterystaple. But for the curious, that table and respective stats would look like this:
Assuming bcrypt on 8 x A100s: 406 nonillion years (that’s a LOT of zeros!)
BUT the xkcd password is not a randomly generated password. Passphrases are a string of known dictionary words. That means “cracking” will be less than 14 Quadrillion years because when selecting which combinations of things to crack first we can start with relatively short, easy to memorize, words! The process can be sped up even more if we know anything about the person and can focus on words from topics we suspect they are interested in. It can even be narrowed by knowing which passphrase generator or dice kit they used. It will still take a long time to crack passphrases but nowhere near as long as fully randomly generated strings of the same length. Even so, if passphrases will get you into those higher character counts then the benefits may outweigh the risks.
For more information and a nice explanation of the xkcd comic.
“Should I trust LastPass?”
You should perform a risk assessment and ensure your risk modeling technique includes modeling the risk of security controls themselves (try using Derive to help!). The days of conveniently assuming security technology came with only benefits and no risk are over! Check out our ACT post on the topic to help with your decision.
But if you don’t have the resources to do that, trusted security professional Daniel Miessler said in My Philosophy and Recommendations Around the LastPass Breaches, “In short, all companies can be hacked, including companies like LastPass, and it’s much better to have your most sensitive assets with a large company that has nearly infinite security resources to detect and respond when it inevitably happens.” which I generally agree with as a heuristic if you don’t have time to do a proper risk assessment.
“Ok but what’s the deal with these huge numbers?”
Different countries, regions, and schools of thought use different abbreviations for numbers. The password table uses the following:
Commas | Zeros | Sci | Log10 | Abbrev | Word | e.g. (10^n zeros) |
---|---|---|---|---|---|---|
1 | 3 | 1.00E+03 | 3 | k | thousand | 1,000.00 |
2 | 6 | 1.00E+06 | 6 | m | million | 1,000,000.00 |
3 | 9 | 1.00E+09 | 9 | bn | billion | 1,000,000,000.00 |
4 | 12 | 1.00E+12 | 12 | tn | trillion | 1,000,000,000,000.00 |
5 | 15 | 1.00E+15 | 15 | qd | quadrillion | 1,000,000,000,000,000.00 |
6 | 18 | 1.00E+18 | 18 | qn | quintillion | 1,000,000,000,000,000,000.00 |
7 | 21 | 1.00E+21 | 21 | sx | sextillion | 1,000,000,000,000,000,000,000.00 |
8 | 24 | 1.00E+24 | 24 | spt | septillion | 1,000,000,000,000,000,000,000,000.00 |
9 | 27 | 1.00E+27 | 27 | oct | octillion | 1,000,000,000,000,000,000,000,000,000.00 |
10 | 30 | 1.00E+30 | 30 | non | nonillion | 1,000,000,000,000,000,000,000,000,000,000.00 |
11 | 33 | 1.00E+33 | 33 | dec | decillion | 1,000,000,000,000,000,000,000,000,000,000,000.00 |
12 | 36 | 1.00E+36 | 36 | undec | undecillion | 1,000,000,000,000,000,000,000,000,000,000,000,000.00 |
13 | 39 | 1.00E+39 | 39 | duod | duodecillion | 1,000,000,000,000,000,000,000,000,000,000,000,000,000.00 |
14 | 42 | 1.00E+42 | 42 | tred | tredecillion | 1,000,000,000,000,000,000,000,000,000,000,000,000,000,000.00 |
Limitations of Our Work
Cracking passwords this way assumes that the attacker has acquired a hash digest of one or more passwords, such as those found in password data breaches on HaveIBeenPwned or more recently LastPass (see that password table here)!
The implied attack assumes that MFA is not used or has been bypassed. If you can get access to download the encrypted database, like what happened with LastPass, you don’t need to deal with MFA when making attempts thereafter.
These metrics assume that passwords are randomly generated. Non-randomly generated passwords are much easier and faster to crack because humans are fairly predictable. As such, the time frames in these tables serve as a “best case” reference point. Passwords that have not been randomly generated would be cracked significantly faster.
These metrics assume you’re using a password that has not been part of a breach in the past. Attackers will try hashes to all common and breached passwords before bothering to crack new ones.
Think of how vast the LastPass breach was. 30 million customers’ secrets were stolen. But as of publishing this article, you won’t find the LastPass breach represented in HaveIBeenPwned. Why? Because the trove of passwords hasn’t surfaced in public yet! Imagine how many stolen secrets and vulnerabilities never reach the light of day or even the dark web. I’d speculate keeping secrets secret gives more leverage and power to criminals than releasing them.
Hashcat defaults to 999 iterations for PBKDF2 SHA-256 but that doesn’t represent what people use. NIST recommends a minimum of 10,000 iterations and sites like LastPass (now) use 600,000, and 1password 650,000 iterations.
Hashing a bunch of character combos is only one step to “cracking.” The second step is looking for matches between the hashed strings and the breached hashed password dataset. We assume that this lookup requires a trivial amount of additional computation and time.
The password breaches that make it to HaveIBeenPwned may not be representative of reality. There may be selection and survival bias filtering out cases before they make it on there. For example LastPass had a big scary breach but they don’t appear on HIBP because the actual data hasn’t been shared publicly. It may also be that when people use strong enough encryption, they don’t bother sharing or selling the dataset because nobody will buy it or bother cracking it.
In earlier editions of the table we included all QWERTY keyboard symbols but this year we stuck with the set commonly accepted on most websites and generated by most password generators ^*%$!&@# . That choice only impacts the right-most column of our tables. In other words we excluded the symbols crossed out in the following table:
Encoding | Alias | Character Range | Characters |
---|---|---|---|
ASCII | Lowercase | a-z | 26 |
ASCII | Uppercase | A-Z | 26 |
ASCII | Numbers | 0-9 | 10 |
ASCII | Symbols A | ^*%$!&@# | 8 |
Acknowledgements
Thank you to the over 1 million of you who have seen, read, and shared our work!
Thank you everyone who commented on last year’s Password Table here on the site, on Reddit, Twitter, YouTube, via email and everywhere else! It helps us make the table and our research better every year.
Thank you to multiple people for assisting with translating the Password Table into multiple languages. If you’d like to see the Password Table in your language, please contact us.
Thank you @Chick3nman512 for another year of answering our questions and sanity checking our hashcat results!
References
Hashes per second (H/s) benchmarks were either generated by Hive Systems using hashcat on local hardware or cloud rentals, or were collected from Github repo/gist search results containing other people’s hashcat outputs (e.g. https://github.com/search?q=hashcat+benchmark).
We obtained GPU hardware specs from the manufacturer or www.techpowerup.com/gpu-specs.
Want to see tables from past years?
Looking for high resolution versions to download?
Or in other languages?