60% of MD5 Password Hashes Are Crackable In Under an Hour (theregister.com) 106
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:Rethinking our approach (Score:5, Insightful)
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-uncrackable password for you right now.
Of course, you'll never be able to remember it. Which is why you store it in a password-keeper, encrypted with a strong passphrase (the only thing you do need to remember) and using a strong encryption algorithm like AES256.
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:3)
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:Rethinking our approach (Score:4, Insightful)
Well, any effective throttling mechanism can also be used as a DoS vector.
That may not be how they breach them
While I agree that more software = more attack surface, in the specific case of a password keeper, I think that easily allowing high-entropy passwords increases security much more than using a password keeper decreases it.
Re: (Score:3)
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)
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 do use lockouts, but don't lock it out globally, then IMO they are at risk of a lawsuit.
lol okay. I work with a bunch of website clients and multiple hosting companies. We use systems that lock out by individual IP address all the time. E.g. 5 failed login attempts from the same IP address; that address gets blocked (for X hours).
It's not pointless at all; it works well. It's not a panacea - nothing is - but it's a nice layer.
Re: Rethinking our approach (Score:2)
Agreed, saying that filtering by IP is useless is like saying you should never lock your front door because a motivated burglar can just break your front door down or break a window.
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)
A traditional login system throttles based on the endpoint (ie, the IP address or a specific browser cookie.)
I've never implemented a system like this where throttling would be based on anything other than login.
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.
Throttling requests means if someone knows your username and has sufficient access to attempt login then yes they absolutely can keep you from logging in. Doing otherwise is insecure. If denial of service is a problem guard usernames.
As Tablizer mentioned there should be single purpose authenticators isolated from app servers for handling user authentication. It is unrealistic to expect passwords to co
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: Rethinking our approach (Score:3)
Nah. It was Kash Patel.
Re: (Score:2)
It's the age old conflict between security and cost. Properly hashes passwords are not cheap, they incur a cost for the server every time someone logs in. There is a disincentive for businesses to implement them.
Re: (Score:2)
> However, nobody in their right mind will store a password by simply storing the MD5 sum of the password.
True, but that doesn't mean people aren't doing exactly that. Even salting doesn't defend against the attack as described, although it does mean they have to crack each password in turn.
I've lost count of the number of places I've seen SHA used to hash passwords - likely because "Oh, MD5 is bad, let's use SHA instead", rather than actually thinking about the requirement (say nothing of the bajillions
Re: (Score:3)
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.
Hahahahaha hahahahahahaha hahahahahahahaha hahahahahahahaha hahahahahahahaha hahahahahahaha gasp Hahahahahahahahahahahahahahaha hahahaha Hahahahaha hahahahaha hahahahahahahahaha hahahahahahahaha hahahaha gasp Hahaha hahahahaha hahahahahahaha hahahahahahahaha hahahahahahahaha Hahahaha hahahaha hahahahaha hahahahahaha
Re: Rethinking our approach (Score:2)
Password hashing complexity for the sake of slow processing has been industry standard for a generation. Nobody seems to have any trouble mitigating DOS attacks. It's usually enough to rate limit by IP.
Re: (Score:2)
> /qh->0,uzLCb!51Wlcha4:a?@4Nmr:&^
Well, it's not secure any more!
Tabilizer, do NOT use that password!
> Of course, you'll never be able to remember it. Which is why you store it in a password-keeper, encrypted with a strong passphrase (the only thing you do need to remember) and using a strong encryption algorithm like AES256.
That's the theory. The part I love is that you practically have to store all your passwords in the cloud to make this feasible for most people, which is its own can of worm
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:Rethinking our approach (Score:4, Insightful)
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 your account with a password.
Re: (Score:3)
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)
Almost all replacements for passwords are not implemented as a way to prove you have access.
Yeah, were never intended to. That's why Authentication and Authorization are considered distinctly different operations. Linked in most cases, but not the same.
Re: (Score:3)
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: Rethinking our approach (Score:2)
I bet almost everyone had their passwords written down somewhere.
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: Rethinking our approach (Score:3)
Re: (Score:3)
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)
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)
Re: (Score:2)
It depends on your password manager. I use one that stores everything locally and never goes out on the network for anything, and it's about as good as it gets. Certainly, the slight risk from the extra software is more than outweighed by the ability to use strong and different passwords for every service.
Re: Rethinking our approach (Score:2)
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)
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.
Most people only have access to that via websites, so checking a new password by transmitting it to a third party would be the worst thing they could do.
Re: (Score:2)
Who said the _users_ should do that? Not me and that idea is completely incompetent. Obviously, the system should do that, because, you know, all other password quality tests are done by the system aas well. And, incidentally, HIBP offers a hashed list for download for exactly that purpose.
Seriously, why do you feel you can comment on IT security topics? You do not even understand the basics.
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.
Re: Rethinking our approach (Score:2)
There's a good chance a system from that era would just look at the first N characters of the password.
Re: (Score:2)
of pretty face paced typing
At first I thought the user was entering emojis back in the year 2000, but I suspect that that was a typo.
Re: (Score:2)
I was picturing a woman with a lot of makeup and an affected smile typing loudly, measured. You know she can type twice that fast, but she knows everybody stopped to listen.
Re: (Score:2)
For a fraction of a second, my mind even went to: "paced" meaning "paste(d) in the password".
Re: Rethinking our approach (Score:2)
Re: Rethinking our approach (Score:2)
The summary specifically says this is a vulnerability if password data is exposed in a hack.
It's not about brute forcing against a password server
Re: (Score:2)
Congratulations, you just reinvented the HSM.
Kaspersky Sales (Score:3)
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:Kaspersky Sales (Score:4, Informative)
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 this stuff in a long time, but I think best practice nowadays is to use a salt, a more secure hashing algorithm, and possibly multiple rounds of the hash to slow down attacks.
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: Kaspersky Sales (Score:2)
Re: (Score:2)
My first question on reading the summar was whether the hashes were salted or not.
It's actually irrelevant. Salting is designed to prevent pre-computed attacks - which is not what is being discussed here -, not prevent attempting to crack the hash by brute force. Virtually every attack that exposes MD5 hashes save for MITM a transmission also results in the attacker stealing the salt.
Re: (Score:3)
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)
During each iteration, once the attacker calculates a hash for a specific character combination, they check if that same hash exists anywhere in the dataset — and the larger the dataset, the easier it is to find a match. If a match is found, the corresponding password is flagged as “cracked”, and the algorithm moves along to the next one.
The article about a global salt with an easy hash algorithm (bcrypt or better has been best practice for basically a couple decades). A global salt prevents a precomputed table. And individual salts protects against making tables because it would be a separate table per salt. You are correct that if the individual salts are saved with the hashes, there's not protection from hashing attacks in general. And that's where using an expensive hash algo like PBKDF2 or Argon2 are important.
So then the base of the a
Re: (Score:2)
Global salt is still a risk since you only need to run through an entire database once, but the point is that with a global salt you still need to run the compute cycle once. THAT they can do in under a minute per password. Yes that is a different risk than doing it in under a minute for a large chunk of the database, but the reality is you shouldn't consider *your* account secure with a unique salt per account, because any attack that targets you will start with you - usernames are not typically protected.
Re: (Score:2)
Kerberos implementations often used MD5 in the early days. It was only earlier this year that Microsoft deprecated using MD5 for password hash storage for various parts of Active Directory because a lot of legacy equipment still used the old protocol.
It's not an easy transition since legacy equipment might only implement MD5, and updating passwords from MD5 requires the user to change their password
Re: (Score:2)
Re: (Score:2)
Yeah, a little ridiculous that Microsoft can't even convince people to stop using RC4/MD5, since AES/SHA was available since like Windows Server 2008?
Both methods suffer from the same issues of offline attack.
Re: (Score:2)
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:3)
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 control of the account. There is a protocol for moving PassKeys to a new phone (CXF, CXP) but only Apple supports it.
Schools, supposedly have taught computer literacy for 15 years but password management still seems to be a blind-spot. SOHOs still don't record their product keys and passwords (since one needs an online account to download the software). As, explained above, I do not see the password-one-can't-lose philosophy as good security.
On the plus side, the government services I use, have quietly offered OTP, and it uses SHA256, not the SHA1 mandated by Google and Microsoft. The "otpauth://" URL contains a "&algorithm=sha256" parameter.
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)
You are correct this came around with FIDO2 still paired with WebAuthn. But the passkey is still untransferable out of the provider's cryptographic store. Noting though that both for local storage and online stores, in order to unlock the user has to verify to the authenticator in the methods dictated by policy.
An interesting case might be storing a passkey to your favorite website using the Bitwarden browser extension as the secure store. The Bitwarden extension will have policies on are able to auth to th
Re: Unloseable passwords (Score:2)
Re: (Score:2)
Passwords are subject to Man In The Middle. Passkeys are not. A passkey handshake verifies both you AND the server you are connecting to.
This is not the case. Passwords are protected from man in the middle attacks when secure authentication algorithm such as zero knowledge proofs are used.
Part of the reason I recommend use of asymmetric encryption /w special purpose authenticators to authenticate passwords is the equation changes when secure authentication is employed. Even if you use an augmented system with a strong password resistant to brute force attacks any failure to protect the verifier at the very least enables server impersonatio
Re: Unloseable passwords (Score:2)
Re: (Score:2)
It's true that with additional layers such as TLS passwords can be protected from MITM, but you can't always control how the other end of a connection behaves. It's better to use a mechanism that's stronger from the ground up.
Again passwords are not the issue, it is only the current ubiquitous misuse of technology that is the problem. The argument it is better to deploy something "stronger" by changing all clients and servers anyway doesn't make any sense because it is the same work either way.
The knowledge factor is useful and worth protecting regardless of other technology such as client certs (e.g. passkeys)
Re: Unloseable passwords (Score:2)
Re: (Score:2)
Passkeys are similar to client carts but they aren't quite the same thing.
No, they are the exact same thing merely managed differently and authenticated at a different layer. The security properties of passkeys are inferior to client certs due to the lack of channel binding.
Re: (Score:2)
I recommend use of asymmetric encryption
This is the whole value proposition of passkeys, certs, signing, and encryption into a untransferrable secure store that's unlockable through the policies set by the store.
Re: (Score:2)
Passwords can be protected from MITM by a secure implementation. Passkeys are protected from MITM by standard and their nature.
Passwords are a concept just as PKI is a concept. Both require implementation to exist in the real world. In the case of passwords an example of an implementation is strcmp or a ZKP like TLS-SRP. In the case of PKI examples are client certs or their poorly re-implemented cousin passkeys.
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. :-)
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
Re: (Score:2)
This makes the phone the point of weakness, as there's no access when the phone is missing
I suppose that depends on how or where you store your passkeys. I use Bitwarden (technically Vaultwarden, but functionally the same for this purpose), and mine are stored as part of my Bitwarden data. That means I can use them in my desktop web browser, my phone, etc.
Your other points are definitely valid, but making the phone the "sole point of authentication" isn't an explicit weakness of Passkeys as a technology, only the terrible implementation by major tech providers (and lets be honest, device/vendor
MFA (Score:2)
Re:MFA (Score:5, Interesting)
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's authenticator app is asking the user for the code... for the bad guy's login session.
The user enters the two-digit code they're seeing.
The bad guys are now in, add their own MFA device and exploit everything they can.
The same thing can happen with TOTP. Anything that an end-user can do can be repeated in near real-time. The phishing site asking for your OTP just re-uses it and feeds it into the real place.
We've been shifting our clients to a "compliant device" position. If the desktop/laptop/phone isn't registered in the client's MDM, it isn't allowed to log on. Yes it's got some overhead to it and yes, getting client buy-in is a struggle. But the days of allowing logons from anywhere, any device are dwindling.
Here's a video about how this works: https://www.youtube.com/watch?... [youtube.com]
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.
Re: (Score:2)
We gotta have your cell phone number. Because security, you know.
Phone numbers are not required for most MFA systems, only for SMS which is already considered insecure. Knowing the phone number has nothing to do with most MFA security.
Re: (Score:2)
That's why it's best to use 2FA that is more automated, e.g. a security key. That way the domain name of the site requesting the 2FA authentication determines the response, so phishing sites won't be able to get usable codes.
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.
Re: (Score:2)
It's not md5 collisions that are the problem here, it's poor passwords.
Which is something that we can't actually fix, and maybe have tried for the past 22 years.
As mentioned above, memory-hard algos are better than hashes now.
Nobody will ever break this (Score:3, Funny)
9cc2ae8a1ba7a93da39b46fc1019c481
Re: (Score:2)
"Covfefe"
Re: (Score:2)
That's certainly stronger then the combination to my luggage.
Re: (Score:2)
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.
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?
The solution to phishing is SAS + secure authentication (e.g. ZKP)
What passes for security on the Internet (cleartext password transmission over "secure" channels) is the reason phishing is the worlds number one security threat. The worlds users have been trained to accept insanely dangerous behavior as normal.
What is especially pathetic many of the "MFA" schemes employed today are not even resistant to verifier impersonation.
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)
Who is still using MD5 in 2026? (Score:2)
Vulnerabilities in the algorithm were found in 2004, 05, 06, 07 and 08. And is was widely recommended to not be used any further in 2010.
(I am myself guilty of having written production software with it in 2008, that was deployed in 2009 ... which had to get updated in 2010)