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...
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.