Modulo the whole privacy/vendor lockin issue, passkeys are not a terrible alternative to people without 2FA reusing the same basic password on every single website.
However, when you actually rely on it to secure things, it quickly becomes a massive nightmare - made even worse by it being treated as equivalent to password+2FA.
> made even worse by it being treated as equivalent to password+2FA.
passkeys are significantly more secure than the most widely-used/most popular forms of 2FA, because the most popular forms of 2FA are TOTP and SMS, and both are subject to phishing attacks. A passkey alone is much more secure than the vast majority of password + 2FA combinations.
The only thing stronger than a passkey standing alone is a Security Key, but Security Keys come with a lot of usability downsides that can easily bite the average user, including:
- inconvenience: you have to remember to carry it around with you everywhere (and not lose it!)
- recoverability: you're completely screwed if you lose it and don't have extras that you already previously added to your accounts. (this also means that you need to buy at least two security keys to have a decent recovery story.)
- rotation (have to log in to every single service, one by one, to re-add new key if you change keys)
And if you really want the extra security that a Security Key provides, you can use a Security Key as a passkey.
Blanket statements like this demonstrate a misunderstanding that "security" is just one thing in a single lineal scale.
In reality you have to ask, secure against what? And to answer that meaningfully you need to a thorough threat model for the specific use case of person P and account A.
The same person P will have a different threat model for every account they have.
The D in STRIDE is for denial of service. Passkeys are much worse on this axis than any other solution. You need to evaluate for the specific combination (P,A) how much this matters vs. other criteria.
I don't think this is correct. It's more difficult to steal something from me than to, e.g. repeatedly force password reset emails. From a ux perspective, it may be easier to accidentally kneecap yourself with a passkey, but security wise, they're still probably better since it's harder for someone else to kneecap you.
I'm not sure why you didn't include the rest of the sentence, which made it clear that I was making a very specific comparison to password + phishable forms of 2FA. I was very clearly not making a blanket statement.
Here's the full context again:
passkeys are significantly more secure than the most widely-used/most popular forms of 2FA, because the most popular forms of 2FA are TOTP and SMS, and both are subject to phishing attacks.
>The D in STRIDE is for denial of service. Passkeys are much worse on this axis than any other solution. You need to evaluate for the specific combination (P,A) how much this matters vs. other criteria.
How are passkeys (really, WebAuthn credentials in general) any worse in terms of denial-of-service attacks than passwords?
I think you're trying to make a point about specific passkey/password managers, rather than the actual credentials themselves. Is that accurate?
It seems like his argument is that putting access to valuable accounts on your phone is a bad practice, because if your phone is stolen at the club after the thief watched you enter your code, then the thief can get at your banking, brokerage, crypto, password manager, etc.
But that argument doesn't address how passkeys somehow make that worse.
Sure, if you don't want your valuable stuff stolen, don't put it on your phone. But that's a problem whether you use passkeys or passwords or passwordless links sent to your email or SMS.
The point is that the phone with a crappy 4 digit pin can be used to authenticate everything on every device the user owns that uses passkeys. It's a one stop shop of failure.
The argument is that without your phone, you likely have no recourse to stop the attack. Since your passkey on the phone is what controls your access, now.
To me, it's unclear what the headache is. If the argument is about the consequences of passkeys for most ordinary people, most people are signed into their google account on their mobile device. In that case, your account is compromised anyway if your device authentication is breached.
For Google in particular, password/passkey isn't a binary choice(currently). You can fall back to the password sign-in flow if your device doesn't have a passkey.
This debate is frustrating because it lacks data — it's full of opinions about which risk is worse than which other.
To compare the risks and benefits, we need to know how often people actually re-use passwords, use 2FA, rely solely on their phone screen lock for access to all their accounts, use biometrics, need account recovery, and so on. That data is the only way to settle the debate (and would allow each person can settle it for themselves, perhaps differently based on their circumstances).
Google has most of this data. They should publish it to back up their claims.
The fundamental idea of using asymmetric cryptography to authenticate is good. It is time-proven, and it works in the best interests of users, simultaneously providing improved security. SSH just works (and while it typically lacks fancy UIs for key management, it's irrelevant to the core idea).
The passkeys design, though, has a number of obvious deficiencies and limitations. It is drastically better than ye olde <input type="password" /> but it's not a good standard.
The other alternative is SRP, but no browser vendor had bothered to do anything about this, so it remains a curiosity implemented on a couple websites (with all JS crypto gotchas, so - no good).
