60% of MD5 Password Hashes Are Crackable In Under an Hour (theregister.com)
- Reference: 0183154434
- News link: https://yro.slashdot.org/story/26/05/07/1952206/60-of-md5-password-hashes-are-crackable-in-under-an-hour
- Source link: https://www.theregister.com/security/2026/05/07/60-of-md5-password-hashes-are-crackable-in-under-an-hour/5234954
> Much of the reason password hashes have become so easy to crack is password predictability. Per Kaspersky, its analysis of more than 200 million exposed passwords revealed common patterns that attackers can use to optimize cracking algorithms, significantly reducing the time needed to guess the character combinations that grant access to target accounts.
>
> In case you're wondering whether there's a trend to compare this to, Kaspersky ran a prior iteration of this study in 2024, and bad news: Passwords are actually a bit easier to crack in 2026 than they were a couple of years ago. Not by much, mind you -- only a few percent -- but it's still a move in the wrong direction. "Attackers owe this boost in speed to graphics processors, which grow more powerful every year," Kaspersky explained. "Unfortunately, passwords remain as weak as ever."
"This World Password Day, the main message ought not to be to the users, who often have no choice but to use passwords anyway, but to the sites and providers that are requiring them to do so," said senior IEEE member and University of Nottingham cybersecurity professor Steven Furnell. His advice is that providers need to modernize their login systems and enforce stronger protections, because users are often stuck with whatever security options they're given.
[1] https://nationaltoday.com/world-password-day/
[2] https://www.kaspersky.com/blog/passwords-hacking-research-2026/55743/
[3] https://www.theregister.com/security/2026/05/07/60-of-md5-password-hashes-are-crackable-in-under-an-hour/5234954
Kaspersky Sales (Score:2)
Here's the real [1]backing article from Kaspersky [kaspersky.com]. Shame that there is no mention that individual salts before hashing have been best practices for many, many years. They of course have a vested interest in scare tactics to sell their password manager product.
That said multi factor auth, long pass phrases, and passkeys are definitely more secure and good advice. But something like Bitwarden might be a better choice.
[1] https://www.kaspersky.com/blog/passwords-hacking-research-2026/55743/
Re: (Score:3)
Back in 2004 or 2005, when I was just some kid in high school playing around making a little website with PHP, I used salted hashes for password storage because that's what the PHP 4 docs recommended. It's not that hard.
My first question on reading the summar was whether the hashes were salted or not. I followed some of the references in your link and ended up at [1]https://securelist.com/password-brute-force-time/112984/ [securelist.com], which indicates that these password hashes are indeed salted.
> The results in the table are calculated for the RTX 4090 GPU and the MD5 hashing algorithm with a salt.
I haven't looked into thi
[1] https://securelist.com/password-brute-force-time/112984/
Re: (Score:2)
Individual being the keyword on the salting. If there's no salt then there's no reason to hash with the card because all the passwords can just be looked up in a plain rainbow table. Using the same salt across all the passwords, then leads to the scenario the article is talking about where you can try salts with known passwords until you get a collision in the db then build a table by hashing every outcome.
That would be the case of storing something like hashed value of globalsalt-thisisbobspassword and glo
Re: (Score:2)
Ah, thanks. Pretty sure the PHP 4 docs in 2004 recommended individual salting. Save each salt alongside the hash. A global salt is just a really odd combination of doing a little more but still being lazy. They probably did it to make their study achievable.
My friend in high school made a website and rolled his own hash function. I was able to brute force every password in a reasonable amount of time with interpreted PHP code on a 667MHz Celeron. It didn't help that he failed to sanitize inputs; the A
Re: (Score:2)
> Shame that there is no mention that individual salts before hashing have been best practices for many, many years.
Salts by their nature are required to be used along side MD5 hashes. The salts exist only to prevent MD5 attacks from being pre-computed. In any kind of proper data breach where an entire database of password hashes are exposed, universally the salts are stolen as well. It doesn't do much against this kind of attack.
Re: (Score:2)
> My rainbow table from 2004 has hashes for every combination of 0-255 (not just printable ascii) up to 256 bytes long.
256 bytes is 2kbits which means your table has to have 2^2048 entries? I doubt that. If you took every atom in the universe and turned it into its own universe, and did that 3 times, the number of atoms in the resulting universe of universe of universes would still be less than 2^2048.
Re: (Score:2)
And yes, even with reduction functions, there's no way you can build a rainbow table holding 2^2048 possible hashes.
Unloseable passwords (Score:2)
Every corporation is demanding online customers use PassKeys or Facial Recognition to secure their account: Neither are safer.
Facial Recognition is a problem because one's face is always there and can be photographed for later break-ins to any secured device. It stops opportunistic thieves, not a planned robbery. Similarly, PassKeys are really passwords the user never touches: This makes the phone the point of weakness, as there's no access when the phone is missing, and whoever has the phone has cont
Re: (Score:2)
> Neither are safer.
Clearly the they disagree because PassKeys are hard to steal. And they have a vested interest in cracking down on stolen accounts.
> Similarly, PassKeys are really passwords the user never touches: This makes the phone the point of weakness, as there's no access when the phone is missing, and whoever has the phone has control of the account. There is a protocol for moving PassKeys to a new phone (CXF, CXP) but only Apple supports it.
The non-transferability by being cryptographically signed against the store is part of the selling point here. Not only do they need "the phone" (noting that passkey can be stored on security keys, a TPM on a desktop, or in independent password managers), but also access to the account that stored the secret. Meaning that two factors are needed, something you have and something y
Re: (Score:2)
> The non-transferability by being cryptographically signed against the store is part of the selling point here.
Having some sort of hardware token or local secure enclave was part of the original promise of passkeys - but it sure seems like that was discarded, now that they can be stored in a wallet which is usable across multiple devices.
I'm open to (citation-supported) correction on that, of course.
Re: (Score:2)
Using SHA1 as an HMAC is [1]safer [stackexchange.com] than using it as an ordinary hash function. I doubt that anyone will be able to reverse-engineer your shared secret by intercepting a few of your 6-digit pass codes.
[1] https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure
Re: (Score:2)
> Every corporation is demanding online customers use PassKeys or Facial Recognition to secure their account:
Every? Demanding? While I don't necessarily disagree with the rest of your post, those two claims are wildly hyperbolic. I haven't encountered any demands to use passkeys for any of my logins anywhere. Yes, many sites offer them as on option, but that's it. Just sayin' ... settle down, no more coffee for you. :-)
Re: (Score:2)
That is false. Both facial recognition and resulting passkeys are very much losable as they are tied to any given device. Just because your face is the same doesn't mean the resulting auth token is the same on another device (in fact it's not). Passkeys very much can be regenerated.
Passkeys tied to devices are in fact safer than passwords as they prevent your account password credentials from being transmitted over the internet. Your device certifies you, the service you connect to certifies your device. If
MFA (Score:2)
With MFA, it should not be a catastrophe if someone obtains your password. That's the point of it.
Re: (Score:2)
> With MFA, it should not be a catastrophe if someone obtains your password. That's the point of it.
MFA is - to a certain degree - compromised.
There are real-world exploits for - for instance M365 - that work like this:
A user gets a malicious, disposable link via e-mail.
The user clicks the link.
The link takes them to a carefully crafted web site, and asks for their username & password.
The user has been partially phished.
The web site initiates an logon call back to M365 in the background and harvests the two-digit code that the end-user needs.
The web site displays the two-digit code.
The user
Re: (Score:2)
> If the desktop/laptop/phone isn't registered in the client's MDM
We gotta have your cell phone number. Because security, you know.
My favorite coffee shop has had a reward system for years based on entering your phone number. Any number would do. And it's only for cents off on your next order, so who really cares?
Then they switched POS providers. Now, the phone number entry screen pukes if it's not a mobile number. I had been using my land line number for years. But nope. We can't pester you to download our app on a POTS line.
Re: (Score:2)
>> If the desktop/laptop/phone isn't registered in the client's MDM
> We gotta have your cell phone number. Because security, you know.
As it happens, MDM doesn't (necessarily) need that. AFAIK you can use a tablet or a phone with Wifi only. And I mentioned MDM-managed desktops and laptops.
While yes, situations like your anecdote exist, MDM isn't some excuse for capturing employee data.
Re: (Score:2)
> MDM isn't some excuse for capturing employee data.
When I think of MDM, I think of an employer-employee relationship. Where, as a condition of employment, the employer has the right to know the devices connected to its network. And in many cases, control their configuration.
As far as capturing employee data, that's also a different environment than one between a business or service provider and a client. I understand completely why getting client buy-in is a struggle.
MD5 To Be Considered Harmful Someday (Score:2)
That seminal paper was published in 2004. Yes here we are, 22 years later
Some people were asleep at the wheel.
Re: (Score:2)
There are a ton of people that stop learning when they are young and a ton of people that never learn why you do something and how to spot when that reason becomes invalid. Many "coders" have that problem.
Nobody will ever break this (Score:2)
9cc2ae8a1ba7a93da39b46fc1019c481
Re: (Score:1)
"Covfefe"
Re: (Score:2)
That's certainly stronger then the combination to my luggage.
Use Argon2id (Score:2)
Using a proper password hashing algorithm mostly addresses this concern... and standard cryptographic hashes like MD-5, SHA-1, SHA-256, etc. are not appropriate. They're designed to be as time and space-efficient as possible while still achieving their security goals. Password hashing functions (more precisely, password-based key derivation functions) are designed specifically to be time and space-hungry, efficient enough that you can execute them in half-second or so for user authentication, but slow eno
Re: (Score:2)
MFA on top of user/password is still helpful though. Obviously, if someone gets phished, that's difference. But phishing is social engineering and not actually defeating the encryption.
I doubt we'll ever solve phishing unless we get rid of the human element but without the human element, what's the point?
It's like saying my server that's turned off, buried in cement and guarded by dogs that shoot bees when they bark is some how a "good" system. It's secure, but it's really rather useless.
Re: (Score:2)
Not "helpful", but "critical". Bad passwords can still be guessed with Argon2, it just takes a lot longer. For high security, 2FA is the only realistic option.
Whew, the database shows my password as: (Score:2)
5f4dcc3b5aa765d61d8327deb882cf99
Who uses MD5 today? (Score:2)
These people are basically medieval by computer standards. The standard is Argon2. Use that or you are simply one thing: incompetent. Also, if you need high security, 2FA is the only thing that works, unless you have very atypical users with the really uncommon skill of being able to select and use secure passwords.
A user gets a malicious email! huh! (Score:2)
This works because people have access to tools they are incapable of using safely, Oh well! such is life.
Rethinking our approach (Score:2)
The "requirements" for a secure passwords will keep trending up such that harassing users to write War and Peace to log in is a dead end.
The password server should be in a special box that throttles requests. It would have a very limited and primitive interface to the outside world; technicians would have to physically unlock it to service it. There would be a mirror server for a backup.
That way no hacker can run gajillion retries on a password without swiping the actual box.
Re: (Score:2)
Great, so now attackers can easily DoS your login system.
Besides, most password-strength analyses assume the attacker has full access to the file of encrypted passwords.
However, nobody in their right mind will store a password by simply storing the MD5 sum of the password. It will be salted and stored with a large number of rounds of a more secure hashing function which makes the crackers' job much harder.
You don't need to write "War and Peace". I will generate a perfectly secure, practically-uncrac
Re: (Score:1)
> so now attackers can easily DoS your login system.
What keeps them for doing that with a traditional system? Even a traditional login screen should be throttled.
> Which is why you store it in a password-keeper
Another vector for hacking.
Re:Rethinking our approach (Score:5, Insightful)
A traditional login system throttles based on the endpoint (ie, the IP address or a specific browser cookie.) I read your setup as a global throttle. If that's not what you meant, then fine; I'll explain why throttling doesn't work: Attackers have armies of machines at their disposal as part of a botnet, and they can distribute their cracking attempts so it doesn't look like any one particular machine is trying too often.
And if you lock an account after a certain number of incorrect guesses... we're back to the DoS situation, where anyone who knows or can guess your login name (often your email address) can lock you out of your account.
Yes, a password keeper is a vector for hacking. But if your password keeper is locally stored on your computer, it's a very distributed target compared to getting a juicy list of encrypted passwords from a big web site. Hackers are going to spend mountains more effort trying to hack LinkedIn than they are trying to sniff around my PC to try to find my encrypted passwords.
Password keepers are also good for ensuring you don't use the same password on multiple web sites. Because if you do, then someone figuring out your Pintrest password might also get hold of your online banking password, since they are the same.
Re: (Score:1)
I'm not understanding why the traditional approach doesn't need throttling. Keep in mind a DOS attack is usually considered a smaller "sin" than a breach(es). If you allow too many retries, then the second sin is more likely. I see no third option*, it's either a DOS freeze or lots of retries.
If hackers find a design weakness in your company's preferred/required password-keeper, they can potentially hack them all. A company can allow multiple keeper brands, but then they either have to vet them all, or acce
Re: (Score:2)
What I'm saying is this: Throttling is ineffective if you base it on IP address (because attackers have nearly unlimited numbers of those) and is a DoS if you don't consider the IP address.
While password keepers can be subject to attacks, because they let you use long and random passwords, an attacker obtaining the encrypted vault is probably not going to be able to decrypt many passwords, as opposed to not using a password keeper and using passwords you can memorize. I think you are not really understan
Re: (Score:1)
> Throttling is ineffective if you base it on IP address...
I didn't dictate any specific throttling algorithm. You are stabbing a strawman.
> an attacker obtaining the encrypted vault is probably not going to be able to decrypt many passwords,
That may not be how they breach them. It's an extra layer or device that may have an inadvertent security flaw. The more turtles in the stack, there more turtles there are to hack.
Re: (Score:2)
One thing the security industry utterly whiffed at was "ALL PASSWORDS MUST BE UNIQUE!" psychology.
No. They Don't. All IMPORTANT passwords need to be unique. But my /. password? is wildly similar to dozens of other website comment section passwords. There's literally no risk to me if it's discovered.
The psychology of screaming to someone a throwaway password needs to be 40 chars of random specials, means they don't follow the instructions when it IS important.
Re: (Score:2)
> And if you lock an account after a certain number of incorrect guesses... we're back to the DoS situation, where anyone who knows or can guess your login name (often your email address) can lock you out of your account.
No, because (in good setups) you lock out per IP address. The botnet machines locked themselves out, but they didn't lock me out.
Re: (Score:2)
No, if you base it on IP address, then it's pointless to lock out attackers because they have more IP addresses than you can ever hope to lock out. And consider your authentication system design, potentially having to keep track of tens of millions of locked IP addresses per user account...
I have never encountered a system that took IP addresses or even networks into account when deciding whether or not to lock an account. If an organization is aware that someone is trying to crack your account and they
Re: (Score:2)
> I read your setup as a global throttle.
I didn't get that impression at all. Personally, I think you jumped all over this guy for no reason.
Re: (Score:2)
I get DOS'd often. I have an email address that is very a common name, and people when drunk THINK it's their email address and attempt to "recover password" too many times until my account is locked. It happens about once a month, and is very annoying.
Re: (Score:2)
heh, I did this to 'not me' once. I was trying to remember if I'd created a gmail in my normal name pattern. Finally after a few fails, I just emailed the address explaining this and just asked if there was a live person there.
They replied yes.
And silly me I believed them!
Re: (Score:2)
Almost all replacements for passwords are not implemented as a way to prove you have access. They are implemented in a way that forces you to uniquely identify as a specific human being. There is a difference. I will continue to use passwords until there is no other option because a password does not compromise my identity or tie my account to a named human.
Re: (Score:2)
In general, the newer methods are ways to associate you with controlled access to known device or keystore. The authentication and identification is against that account. This shouldn't be confused with using social login, which big identity providers being more likely to be on the more cutting edge of offering those methods. But if a independent provider let you use a passkey that you store in an independent password manager or lets you use a second factor with TOTP those don't identify you any more than y
Re: (Score:3)
> ... because a password does not compromise my identity or tie my account to a named human.
Also, they're "something you know" and in the U.S. anyway people are generally afforded 4th and 5th Amendment protections against disclosure, while bio-metrics and (probably) passkeys aren't.
Re: (Score:2)
When I ran my company, that's exactly what we did. We picked people's passwords for them and did not let them change the password. If they wanted to change it, then we generated a different random one for them.
My rationale was that if we got hacked and the passwords were leaked, at least those passwords were very unlikely to be useful on any other sites used by our customers. Unless they loved our password so much they reused it, I guess... but that's not too likely.
Re: (Score:1)
The random ones are too hard to remember, most will copy and paste. Either that, the help-desk is swamped with resets.
Re: Rethinking our approach (Score:2)
Hey! ******* Is my password
Re: (Score:2)
> The password server should be in a special box that throttles requests.
There is no passive defense that can save you without creating new problems. A slow server is a DDoS-able server. We already do things like rate limiting, but it can also be a problem. Therefore we use active threat detection and selective blocking.
> That way no hacker can run gajillion retries on a password without swiping the actual box.
It's not wrong to want to put your authorization server on a link that's too dumb to hack it through, but what about local logins? We have good reasons to protect our password databases.
Anyhoo the best kinds of passwords are phrases with subtle errors or small ra
Re: (Score:2)
> Anyhoo the best kinds of passwords are phrases with subtle errors or small random changes
No, that is not true. The best kinds of passwords are long sequences of characters derived from /dev/random . Using a cryptographically-secure random number generator to make a password with as much entropy as possible, is provably better than anything else.
I guarantee that nobody will crack something like k$18aWIpbQuo(s!opM2eKCiotu,W?jvr There are plenty of password-cracking tools that introduce "subtle errors"
Re: (Score:1)
A good password needs to be something a human can type in. Password managers aren't sufficiently secure, robust, universal, or user friendly.
Re: Rethinking our approach (Score:2)
Just use passkeys. Problem solved.
Re: (Score:2)
Actually, the opposite. High "password quality" requirements are reliably known to be counter-productive. The only way to reliably get better security is with 2FA or MFA.
You should check new passwords against the "Have I been Pawned" hashes and the Kali password lists, but that is it. If it passes that, it is as good as it gets.
Re: (Score:2)
I remember back in the early *2000s* a coworker typing in their password and it was probably 20-25 seconds of pretty face paced typing. Had to have been 60+ chars. Like there was a significant noticeable pregnant pause in the small talk while they logged in.