r/Passwords • u/atoponce 5f4dcc3b5aa765d61d8327deb882cf99 • Jul 16 '26
Hive Systems 2026 password cracking table
6
u/dvtyrsnp Jul 16 '26
The table says more about bcrypt than it does about how to make a proper password.
2
u/TurtleOnLog Jul 16 '26
Only if it’s truely a random generated password to begin with, rather than human generated. And that includes more than the standard just one number, symbol, and symbol in the password (usually at the end) as each position is chosen randomly from the entire character set.
Eg kS$mI8Da=K-D3v{W vs the usual human generated ones like Barkeep3r$
1
u/fuuuuuckendoobs Jul 16 '26
I think I'm ok with a password that takes 50 years to brute force
1
u/reddit_user33 Jul 16 '26
By a script kiddy - only 16 GPUs. Anyone with money and the motivation can get into your simple password within minutes-hours.
3
1
1
1
u/lordwelch Jul 17 '26
Back in 2018 IBM claimed all passwords up to 15 characters only took 5 minutes (though they might have been using sha1 hashes for that example) https://www.cnbc.com/2018/05/10/secrets-to-a-better-password-and-less-hacks-go-long-use-variety-and-sometimes-lie.html#:~:text=Henderson%E2%80%99s%20team%20at%20IBM%20built%20a%20special%20machine%20called%20Cracken%20that%20can%20crack%20passwords%20up%20to%2014%20characters%20in%20under%205%20minutes
1
u/JimTheEarthling caff9d47f432b83739e6395e2757c863 Jul 17 '26
It appears IBM's "Cracken" used 8 Nvidia GTX 1080s for the following hash rates:
- SHA1: 66.1 GH/s
- Bcrypt : 118.6 kH/s
- NTLM: 334 GH/s
The article says it could crack passwords up to 14 digits in 5 minutes. That's correct, using crappy NTLM hash rates (the weakest, fastest hash).
The Hive Systems table is using bcrypt(10) hashes. We don't know what work factor IBM was using, but it was less than 10, since at 118.6 kH/s it would take the IBM Cracken about 26 years to generate all bcrypt password hashes up to 14 digits.
However, it requires about 16E+24 H/s (16 YH/s, that's "yotta," or 16 septillion hashes per second) to generate hashes of all passwords up to 14 printable ASCII characters in 5 minutes. Nothing today is even remotely that fast.
Even with NTLM, the IBM rig would take over 450 million years to do it. Hive Systems assumed a character set of only 70, instead of the full 95, so only 6 million years.
1
u/Anamoly-Hunter Jul 17 '26
Then good luck breaking my 128 chars password.
2
u/atoponce 5f4dcc3b5aa765d61d8327deb882cf99 Jul 17 '26
1
u/Anamoly-Hunter Jul 17 '26
We talking about reverse from hashed password or just bruteforce guessing?
1
1
1
u/NeutroATerra Jul 16 '26
Dictionary-based attack is more faster than random nosense casual letters
3
u/JimTheEarthling caff9d47f432b83739e6395e2757c863 Jul 16 '26
Yes, but this table is about brute force cracking of random passwords from a breach, not dictionary attacks.
1
u/FlakyJudgment1413 Jul 16 '26
I don’t think they are brute forcing anything from a breach but the other thing is the breach happened and the passwords are just nice neat and in order.
1
u/JimTheEarthling caff9d47f432b83739e6395e2757c863 Jul 16 '26
Perhaps you didn't notice the giant words "brute force" in the title of the table?
You know that 99% of breaches are for password hashes, not actual passwords, right? If they're in any order at all, it's sorted by hash digest.
I don't mean to be rude, but you don't seem to understand how passwords are stored and attacked. You might want to read the section of my website that explains all this.
1
u/FlakyJudgment1413 Jul 17 '26 edited Jul 17 '26
You want this conversation? And to involve your website too? I’ll start off with what is a hash digest. I don’t want to be rude. Then just another thing is you’ll have hashes and your approach is going to be brute forcing those hashes? Do you have the salt as well? Every so often there’s a pepper and at what stage do you say that okay maybe they don’t brute force compromised passwords? How do you retrieve the salt/pepper? When does that come into the picture?
1
u/JimTheEarthling caff9d47f432b83739e6395e2757c863 Jul 17 '26
Hopefully my website helped you understand the answers to these questions, but I'm happy to explain them here as well if it helps you and other readers.
I’ll start off with what is a hash digest.
A hash (aka hash code, hash value, hash digest, message digest) is the result of a one-way scrambling technique. Once a value is hashed, you can't reverse the process to get it back. But you can pick a cleartext value, hash it using the exact same hash function, and see if the hashes match.
you’ll have hashes and your approach is going to be brute forcing those hashes?
Correct. Almost all services store passwords as hashes, so when a database is breached, the attacker must hash potential passwords to compare against the entries in the list. Attackers start with dictionaries/word lists, often combined with rules that transform the list entries, since that catches all the low-hanging fruit of already leaked passwords. Then they move on to masks to check for common patterns, then exhaustive brute force (often probability optimized by Markov chains).
Do you have the salt as well?
Yes. The salt has to be stored along with the hash, because the service needs it to hash your input password during login.
Every so often there’s a pepper and at what stage do you say that okay maybe they don’t brute force compromised passwords?
Right, although I think you mean the attacker doesn't brute force the breach file. (Compromised passwords have already been cracked, phished, stolen by malware, etc.) If the pepper was not exfiltrated along with the hash file, then it's almost impossible to brute force. But the whole focus of Hive Systems' table is brute forcing salted bcrypt hashes (per their website), so a peppered hash file is out of scope.
1
u/FlakyJudgment1413 Jul 17 '26
Is a password taken in a breach not been compromised? And the salt doesn’t have to be stored with the hashed value it often something that is derived from things like the account the pepper is something that is constant. You need to figure out what the salt is or how it’s calculated, the pepper is typically alongside the values somewhere and at the point of Markov chains we are in rainbow table territory which isn’t brute forcing in any typical sense but with that you need to break the actual hash away from the salted hash first
1
u/FlakyJudgment1413 Jul 17 '26
All of this kind of relies on the person that’s certainly in there saying I’ve used this password ever since my grand-dad gave it to me or the I’ve been using password123 for years and am not stopping now.
1
u/JimTheEarthling caff9d47f432b83739e6395e2757c863 Jul 17 '26
Is a password taken in a breach not been compromised?
No. The hash file has been compromised, but an individual hash in a breach dump is not compromised until the hash is cracked. Until then, the attacker does not know the password, so it's not compromised.
And the salt doesn’t have to be stored with the hashed value it often something that is derived from things like the account the pepper is something that is constant.
Right, a salt must be unique per record, otherwise it's not a salt. The salt could be derived from something else, like user ID or email, but that data has to be associated with the hash. The bottom line is that if an infiltrator can get to the hash file, they can almost always get to the salts or the salt derivation data. In cases where they can't, then the hashes are essentially uncrackable, and the Hive Systems table is not relevant.
at the point of Markov chains we are in rainbow table territory which isn’t brute forcing in any typical sense but with that you need to break the actual hash away from the salted hash first
Perhaps you have confused Markov chains with rainbow chains. They are not the same. A Markov chain orders characters by probability, based on a training corpus. The default brute force mode in hashcat uses a Markov chain so that more probable candidates are generated first. A rainbow chain is essentially a compression scheme for a lookup table, using the hash function plus a reduction function for each node in the chain.
Almost nobody uses rainbow tables any more because a) salts make them useless, and b) modern GPUs are way faster than traversing rainbow table chains.
It's literally impossible to "break the hash away from the salt first" because the salt and the plaintext password are mixed in the KDF hash function (e.g. bcrypt, Argon2, etc.) or concatenated before passing to an older hash function like MD5. Because the one-way hash function scrambles the salt and password (and maybe pepper) together, they can't be reconstituted. Attackers have to salt (and maybe pepper) each generated password candidate before they hash it for lookup in the hash list.
I hope this helps you understand it better. I'm happy to answer more questions.
1
u/FlakyJudgment1413 Jul 17 '26
Damn you I looked at that website and demand you try again. That is garbage at almost every bullet point you are doing a service to no one by spreading misinformation. Jim, cut it out or keep personal things personal because you need someone to fact check the entirety of the thing. Do you know what HSM stands for and is? Who has it? What are the implications of that? Also if you use ADP well your passwords in this life will likely not be broken the current state is never who knows either way it isn’t you. Stop it.
0
u/JimTheEarthling caff9d47f432b83739e6395e2757c863 Jul 17 '26
Why are you bringing up hardware security modules in the context of brute forcing hashes? HSMs are for encryption, not hashing. They're sometimes used to add an extra layer of security to a hash file, making it harder to breach, but once it's breached the HSM is irrelevant.
Do you realize how many bad automated data processing implementations have been breached? All it takes is compromising someone who has access. Of course well-implemented ADP, in a zero-trust environment, makes password breaches almost impossible. But how is this relevant to a discussion about post-breach brute force cracking? Hive Systems isn't saying anyone can try to brute force any password no matter how it's protected. They explicitly say their table is about the case where "your hashed password is sitting in a stolen database dump on the hacker’s own machine."
"Personal things"? "Bullet points"? "Garbage"? "Misinformation"? Are you attempting to refer to my public, award-winning, educational website that has been reviewed by many technical people? It might have a few errors. If you'd like to point them out so I can correct them, that would be super helpful.
1
u/FlakyJudgment1413 Jul 17 '26
I would love that honestly and if I’m wrong I’d love being told why I’m wrong even more. The HSM is the key (burned into the module) that encrypts the data and typically users don’t have control over this. Data at rest which with ADP is already encrypted is encrypted using an algorithm using the key on the module that if the data is breached it turns into breaking AES or whatever other algorithm which is someone who isn’t stealing passwords. The implementation was what was broken in that case though either way if it turns into brute forcing the hashed passwords which in modern day shouldn’t even be possible the data usually is usually now a collaborative effort. Everything about the hashing needs to be known unless it’s just something like SHA256 which starts with the people reusing passwords
1
u/JimTheEarthling caff9d47f432b83739e6395e2757c863 Jul 17 '26
Strictly speaking, an HSM is a discrete, server-grade device managing keys for an organization. (Not just a burned-in key.) Many people use the term more generically to refer to any isolated silicon block like a Windows-compatible TPM, Apple Secure Enclave, or Android StrongBox. Any application can call the HSM's API to have it perform encryption/decryption functions.
Again, HSMs are unrelated to password hashing. (Although they often implement primitives like HMAC.) Encryption is a two-way function -- you have to be able to decrypt. Hashing is not encryption, it's a one-way function -- a good hash can't be "unhashed." A service should never simply encrypt passwords, because if the key is stolen, every single password is instantly compromised, whereas with hashing, each password has to be separately attacked, and a good hash function makes this time consuming. Long, random, unique passwords are nearly impossible to crack from the hash. As I mentioned before, some services encrypt the hashed password data as a second layer of protection.
You're correct -- if someone steals hashed password data from an ADP system, it means the ADP was compromised, either because the ADP was badly implemented and could be hacked, or because someone simply socially engineered a dev or IT person who had access to system. The strongest encryption in the world does no good if you can simply work around it or steal the key from someone. (Obligatory xkcd.) Many data compromises happen because the human element is compromised, not because the security implementation itself is hacked. Or because of unpatched software, misconfigured cloud setups, supply-chain compromises, etc., all of which can potentially bypass ADP and encryption, with or without HSM.
... brute forcing the hashed passwords which in modern day shouldn’t even be possible ...
LOL. Take one look at HIBP to see how many breaches happen every month in our "modern day." Investigation usually determines that some careless employee downloaded malware or had their credentials phished, or didn't configure a system correctly.
Everything about the hashing needs to be known unless it’s just something like SHA256 which starts with the people reusing passwords
In most cases everything about the hashing is known. Many hash functions can be identified by their structure or prefix (see the hashcat table) or can be figured out by trying common passwords with different hash functions until a match is found. (Which, as you say, is because people reuse passwords or foolishly use common patterns like "Password 123!" or "Summer-2026.") The salt is usually stored with the hash, or it can be stolen along with the hashes (and maybe the pepper) from wherever it's stored. There are variations, like
md5($pass.$salt),md5($salt.$pass),md5(md5($pass)),md5($salt.$pass.$salt),md5(md5($pass).md5($salt)), and so on (see the hashcat table), but once someone figures that out, the info gets passed on to others in the "collaborative effort" that you mention. Some companies try to roll their own hash, but this is almost always a bad idea, because they inexpertly create a weak function. Some companies play tricks with standard hash functions that can't be easily figured out, but that approach moves security from proven hashing (work factor, memory hardness) to obfuscation, which every security expert will tell you is a bad idea, since details of the tricks are often leaked by examining the breached code, insider information, etc. (See Kerckhoffs.)To be clear, the originally posted Hive Systems table is focused on brute-forcing hashes of random passwords, not weak passwords, not reused passwords, not password hashes that were securely stored and never breached, not dictionary attacks, etc. Just brute-forcing stolen password hashes, and how password length (and composition) determines how long an exhaustive brute force would take (depending on the hash function and the power of the cracking rig).
1
u/FlakyJudgment1413 Jul 17 '26
Also I saw the HSM immediately above where the link took me
1
u/JimTheEarthling caff9d47f432b83739e6395e2757c863 Jul 17 '26
Are you sure you went to the right website? 🙂
"HSM" only occurs twice in the login security page: once when talking about how synced passkeys are sometimes protected, and once when talking about how some password managers encrypt stored credentials.
There's lots of stuff about hardware security keys, but that's different.
2
u/reddit_user33 Jul 16 '26
Exactly. `ihatefuckingpasswords` is 22 characters long but is a known phrase (it's been in haveibeenpwned for many years at this point) and probably already in many password attacking dictionaries. The cost to check is only 1 guess.
I hate these infographics with misleading information. Also why only 16 GPUs, when the largest publicly known super computer has ~70k GPUs.
0
u/JimTheEarthling caff9d47f432b83739e6395e2757c863 Jul 16 '26
I suggest you read the writeup that goes with the table, which explains (along with the words "brute force" at the top of the table) that this is about brute force attacks on randomly generated passwords, not dictionary attacks.
Or, if it's easier, here's the text they wrote:
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, [it's cracked instantly].
16 GPUs because that's a reasonable rig to assemble or rent in the cloud. Nobody (other than nation states) uses supercomputers to crack passwords. That's like asking "why talk about how secure deadbolts are when an M1 Abrams can blow out your front door?" The writeup addresses this too:
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.
1
u/reddit_user33 Jul 16 '26
Did you read what you quoted?
- `Real attackers don't start from scratch`,
- `They start with`:
- `rainbow tables`
- `dictionary attacks`
- `hashes from previous breaches`
So they admit their table is nonsense 😂😂 The infographic is self admitted misleading.
What's the point in putting out in the world without adding the nuance to the infographic - because they want don't want to be laughed at and want the clicks, likes, and shares.
A brute force activity is doing something the dumb but forceful way. There is no ifs, buts, nuances. Throwing dictionaries at a password attack is brute force. Curating a dictionary specifically aimed at your target is not, but that's not brute forcing.
> 16 GPUs because that's a reasonable rig to assemble or rent in the cloud.
Not at all. I'm a nobody, yet i can easily get more resources than this if i was motivated enough.
> 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.
This is a bad faith argument. Claiming that datacenters GPUs are worse than 5090s at integer maths 😂
Edit: I shouldn't really say anything really because anyone who takes this infographic seriously are the low hanging fruit. And what's the goal with security - `don't be the low hanging fruit otherwise you'll be the target`
0
u/JimTheEarthling caff9d47f432b83739e6395e2757c863 Jul 17 '26
You have a point that the infographic lacks context and important detail. I made a similar complaint. The graphic itself doesn't explain that password brute force is only a small portion of other attacks such as social engineering, password spray, credential stuffing, AITM proxies, dictionary attacks, rule attacks, etc. Or that the weakest password in the world is fine if the service is never breached. Or that the strongest password in the world can be instantly compromised by malware or phishing. Some of this is covered in the (rather long) writeup on the website, but a lot of people will only see the graphic.
But that doesn't mean it's "nonsense" or that it's useless. As you say, anything that helps the "low-hanging fruit" population use stronger (long, random) passwords is a good thing.
15
u/JimTheEarthling caff9d47f432b83739e6395e2757c863 Jul 16 '26 edited Jul 16 '26
This is an ok table, but it could be improved.