We had originally planned to go all-in on passkeys for ONCE/Campfire, and we built the early authentication system entirely around that. It was not a simple setup! Handling passkeys properly is surprisingly complicated on the backend, but we got it done. Unfortunately, the user experience kinda sucked, so we ended up ripping it all out...
Sure, and then that one password is compromised. Password managers make it trivial to use unique passwords for every service, so if a service is breached, you’re basically as screwed with passwords as passkeys.
The switching cost here is high, and the security benefits are marginal in practice IMO. I’m not against passkeys, but it should be something password managers handle, and I don’t have a strong preference between TOTP baked into your PW manager and passkeys.
Which means that entire service you used that password to login to is compromised. If you were using passkeys however, you would have nothing compromised.
No… with a passkey you would be not screwed at all. You’d be entirely unaffected.
I mean in your own example that’s a reduction of 100%. That’s kind of a huge difference.
If the password is compromised, it means the service is compromised and the password isn’t really protecting anything anymore. So to me, there’s no functional difference between passwords and passkeys once a service is compromised, the data is already leaked. If I’m using proper MFA, there’s no rush to reset my PW unless the service has a stupid “backdoor” that can just bypass MFA entirely, in which case passkeys wouldn’t help either (attackers would just use the backdoor).
The main value of passkeys, AFAICT, is that they’re immune to phishing attacks. Other than that, they’re equivalent to TOTP + random password, so a password manager that supports both provides nearly equivalent security to a passkey (assuming the service follows standards like storing salted hashes). And honestly, if you use a solid form of TOTP (i.e. an app, not text or email), password security isn’t nearly as critical since you can make up for it by improving the TOTP vault security.
I honestly haven’t bothered setting up passkeys anywhere, because I don’t see any real security benefit. If a service provides passkeys, it probably already supported decent MFA and random passwords. The services that should upgrade won’t, because they’ve already shown they don’t care about security by not providing decent MFA options.
In short:
The venn diagram of companies that support passkeys and companies that supported/support random passwords + TOTP is essentially a circle, with the former enclosed in the latter. So I don’t really see any rush to “upgrade.”
Not even close. To be honest you’re operating on so many incorrect assumptions and have such a lack of general knowledge of common attack surfaces or even the average scope of modern breaches, that digging you out of this hole would take so much more than what I can fit in a single comment.
So
No… just no. That isn’t how it works. In reality, what commonly happens is metadata around the service is what’s targeted and compromised. So your password, email, and other data like that are what’s stolen. Maybe in plain text, maybe something hashed that a malicious actor can brute force offline without you knowing. If you’re someone using a password in this situation, your password is then used to access your account, and that actor can do any number of things while masquerading as you, potentially entirely undetected. If you’re using a passkey on the other hand, this isn’t even something you need to worry about. They cannot get access to your passkey because the service doesn’t even have it. You are entirely immune. That is something that no amount of Passwords or bolt-ons will fix.
This is the main value of passkeys, they are not shared secrets. Not only is that a huge difference, it’s the single largest paradigm shift possible. The secondary value of passkeys is that they are immune to phishing. This is also huge, as phishing is hands down the most successful way to break into someone’s account, and happens to even the most security conscious people. If a cybersecurity researchers who write books on the topic can be phished, so too can a layman such as yourself. Hand waving away a phishing immune authentication system is unhinged behavior. And it goes to show you’re not even coming from a place of curiosity or even ignorance, but likely misinformation.
In short:
Passwords are almost never stolen, because most orgs follow OWASP best practices and do salting and hashing, as well as lockouts.
The real issue here is reused passwords, since a breach at one of those orgs that don’t follow best practices could be used to gain access to another service with better practices. If you’re using a password manager to generate random passwords for each service, this most common attack method is neutralized. A salted password hash makes brute forcing completely non-viable, so 99.99% of attackers won’t bother, and the only ones left are state-level actors doing targeted attacks (in which case they’d just use a wrench to get your details).
Sure, but if they can access your password in a breach, they can access anything they want to on the service, so they don’t need your login credentials. If the service is following best practices, leaking login creds doesn’t actually help, so they’ll instead sell the PII they collect from the breach (including email and whatnot). Nobody is going to crack every password in a breach, so if an attacker sees argon2, scrypt, or bcrypt with sufficient work factor/cost (and orgs can easily swap this to keep up w/ standards completely transparently).
If the service isn’t following best practices, they’re not going to offer passkeys because they obviously don’t care about security. The services that could really benefit from passkeys won’t use them, and the services that already follow best practices wouldn’t get much benefit from them because their security is already good enough.
Which is also true of hashed passwords. So if you use randomized passwords and the service hashes those passwords, there is no shared secret. If you add a shared secret (TOTP) as a second factor, and that shared secret is verified using some challenge/response mechanism, you’re covering the same ground as passkeys, just with an extra step.
From a security perspective, passkeys generally double-down on the security protections TOTP (and similar) provides. Yes, they’re theoretically better, but in practice, if a service is using TOTP properly (i.e. no fallback to SMS or whatever), you’re just as protected in practice as with passkeys.
I’d much rather see us switch to something like hardware security keys and FIDO U2F than yet another software solution. A hardware solution ensures you actually have a thing, whereas a digital option like passkeys can be duplicated in enough places that there’s no guarantee you actually have that thing. For example, if you sync your passkeys with your desktop and get a virus, an attacker could login as you w/o you knowing, and that cannot happen w/ hardware keys like Yubikey. A passkey, to me, is a lateral step, whereas a hardware key is a clear step forward because it restricts the ways you can be compromised. I recommend having multiple of these (say, one on your keys and another in a safe), and if you lose one, just disable the key and order another.
True, but it’s rarely end customers that get phished successfully, it’s support staff granting access that they shouldn’t, or other forms of social engineering where they get access to credentials that can access data w/o needing to compromised individual accounts (e.g. get a dev token to access prod data). Passkeys don’t help with that type of attack at all.
That said, I was almost compromised with a phishing-style attack. Basically, I got a call from someone claiming to be from the fraud department for my bank, and they asked me to confirm a SMS code. I fell for the first confirmation (was out and about and didn’t read the text carefully), but caught the second (the one where they were adding a new account to transfer money out). If my bank had supported TOTP, this wouldn’t have happened because an agent will never ask for my TOTP code, so I’d only get SMS from an official rep or TOTP if I’m logging in myself. Passkeys could have helped here, but so could TOTP, and honestly getting an org to support TOTP is probably easier than getting them to use passkeys.
I’m not against passkeys, I just think they’re a largely lateral change from TOTP + password manager, and thus don’t feel a need to switch.
To use the “something you have, and something you know” analogy, your PW manager password can be either (ideally “something you know”), and TOTP is “something you have” (or you could memorize the password and bypass the PW manager; I do that for a handful of services). With passkeys, it’s only “something you have,” and the “something you know” is entirely based on how you access the passkey store. If you use biometrics, it’s only “something you have,” and my understanding is that’s how it’s being marketed (i.e. never remember a password again!!).
In the US, we have legal protections for “something you know” (5th amendment), but much weaker protections for “something you have” (4th amendment). You could lock your passkeys w/ “something you know,” but it makes it so much easier to consolidate everything into “something you have,” which can be subpoenad by law enforcement (i.e. I’m legally obligated to provide my fingerprints if I’m arrested). So if we’re advertising passkeys as more convenient (i.e. switching something you know for something you have), we’re putting more people at risk.
So in short, I see marginal benefits of passkeys over TOTP + password manager, as well as some practical issues. So best case, it’s a largely lateral move from TOTP + PW manager, and a step back WRT law enforcement.