60% of MD5 Password Hashes Are Crackable In Under an Hour (theregister.com) 22
In honor of World Password Day, Kaspersky researchers revisited their study on the crackability of real-world passwords and found that 60% of MD5-hashed passwords could be cracked in under an hour with a single Nvidia RTX 5090, and 48% could be cracked in under a minute. "The bottom line is that passwords protected only by fast hashing algorithms such as MD5 are no longer safe if attackers obtain them in a data breach," reports The Register. From the report: 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.
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.
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: (Score:3)
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 bac
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)
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)
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:2)
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.
Kaspersky Sales (Score:2)
Here's the real 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.
Re: (Score:2)
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 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
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
Unloseable passwords (Score:2)
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 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.
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. :-)
MFA (Score:2)