4 ms·

> Passkeys avoid all of that, but you need backups either in the form of a Yubikey or a recovery code in your wallet. Yes, that’s annoying but there is no world

> Passkeys avoid all of that, but you need backups either in the form of a Yubikey or a recovery code in your wallet. Yes, that’s annoying but there is no world where nobody is annoyed... We're not talking about annoyance here, we're talking about data breaches on the one hand and permanent account lockouts on the other. There is no world where the majority of people remember distinct passwords for each service, and there's likewise no world where the majority of users carry a Yubikey or even download their recovery codes at all, much less carry them with them. So we're left really with two choices at the extremes: do we go for the failure mode where people reuse passwords and lose money and data that way, or the failure mode where a company is physically incapable of restoring a customer's account? Given the choice between these extremes, companies will always choose the former. Now, these extremes aren't the only choices, but then you get to the crux of OP's argument: passkeys stored in a password manager aren't any more secure in practical terms than random passwords stored in a password manager. Your auth system is only as secure as its recovery mechanism (which is the observation that led Slack to initially not bother with passwords at all). There's one way in which I disagree with op, which is that passkeys prevent users from typing in a password and storing it in the password manager, which many users do—they effectively enforce random passwords rather than it being just a best practice that needs to be taught.

jt2190 2y ago
> [D]o we go for the failure mode where people reuse passwords and lose money and data that way, or the failure mode where a company is physically incapable of restoring a customer's account? Are you sure that Microsoft’s solution means that they are “physically incapable of restoring a customer’s account?” Apple’s system keeps copies of recovery keys in their cloud [1], unless you explicitly tell them not to do this. It seems like a reasonable compromise for most people’s security needs. [1] Or effectively something like that.
- lolinder 2y ago
  I get to that, but as I said above you've now compromised the security of the passkey system, which means your passkeys are actually only as secure as your recovery mechanism, and for convenience sake that recovery mechanism is usually quite insecure.
tptacek 2y ago
Sure they are: Passkeys are phishing-resistant, and random passwords are not. This is pretty basic stuff.
- lolinder 2y ago
  Random passwords in a password manager are also phishing-resistant. My password manager remembers the URL that I used the password in and will refuse to fill it in on other pages unless I deliberately work around that protection. They may be less phishing-resistant than passkeys (in which case add it to the list of small disagreements I have with the original poster), but it's not a wide open field for phishing attacks. And this is an important distinction to make—if passkeys have a terrible UX (which right now they absolutely do) and are only marginally better at phishing protection than a password manager, they could actually be a less secure solution overall by encouraging lazy workarounds.
  - afiori 2y ago
    One big selling point of passkeys is that almost every workaround is impossible, whether that is good security or bad UX or both seems to be under discussion
    - lolinder 2y ago
      If that's one of the big selling points then that's a problem, because workarounds are totally possible and actively implemented in the real world. As an obvious example: syncing passkeys is a workaround for their terrible UX that takes them further from the original design in ways that compromise some of the original security guarantees.
      - wglb 2y ago
        Can you illustrate how workarounds to passkeys are being actively implemented?
        2y ago
acdha 2y ago
> passkeys stored in a password manager aren't any more secure in practical terms than random passwords stored in a password manager. This isn’t true, and that’s where your confusion comes in. Passkeys cannot be phished because the protocol includes the server name and does not expose the key to the remote server. The past decade of U2F/FIDO/WebAuth deployment has used that as the marquee selling point because it’s a very common exploit which cannot easily be prevented with traditional passwords and MFA.
- afiori 2y ago
  This ignores that most password managers check domains/origins the same way browsers do. the only difference is maybe in-app browser where the passkey integration might work more easily but even so: 1) it is still a matter of integration and/or using an actual browser 2) in-app browsers are inherently insecure anyway (at least on android)
  - acdha 2y ago
    > This ignores that most password managers check domains/origins the same way browsers do. No, it doesn’t. Most password managers allow you to fill passwords for other domains and all of them allow copy-paste. The people who support those users know that phishers can convince people to do that which is why they’re encouraging adoption of WebAuthn.
  - deleted 2y ago
    [deleted]
7952 2y ago
That assumes the recovery mechanism is definitely going to be a greater risk than phishing. In a corporate setting recovery could require intervention from IT support if alternative methods don't exist. That adds obscurity and natural rate limiting. Where as phishing could be as simple as a fake login page. Another factor here is the number of logins that a user is required to perform. Anecdotally this seems much higher in a corporate setting than personal. I might login to Microsoft SSO 15+ times per day for different services. Signing in to apps on my phone is rare.

jt2190 2y ago

> [D]o we go for the failure mode where people reuse passwords and lose money and data that way, or the failure mode where a company is physically incapable of restoring a customer's account? Are you sure that Microsoft’s solution means that they are “physically incapable of restoring a customer’s account?” Apple’s system keeps copies of recovery keys in their cloud [1], unless you explicitly tell them not to do this. It seems like a reasonable compromise for most people’s security needs. [1] Or effectively something like that.

lolinder 2y ago
I get to that, but as I said above you've now compromised the security of the passkey system, which means your passkeys are actually only as secure as your recovery mechanism, and for convenience sake that recovery mechanism is usually quite insecure.

tptacek 2y ago

Sure they are: Passkeys are phishing-resistant, and random passwords are not. This is pretty basic stuff.

lolinder 2y ago
Random passwords in a password manager are also phishing-resistant. My password manager remembers the URL that I used the password in and will refuse to fill it in on other pages unless I deliberately work around that protection. They may be less phishing-resistant than passkeys (in which case add it to the list of small disagreements I have with the original poster), but it's not a wide open field for phishing attacks. And this is an important distinction to make—if passkeys have a terrible UX (which right now they absolutely do) and are only marginally better at phishing protection than a password manager, they could actually be a less secure solution overall by encouraging lazy workarounds.
- afiori 2y ago
  One big selling point of passkeys is that almost every workaround is impossible, whether that is good security or bad UX or both seems to be under discussion
  - lolinder 2y ago
    If that's one of the big selling points then that's a problem, because workarounds are totally possible and actively implemented in the real world. As an obvious example: syncing passkeys is a workaround for their terrible UX that takes them further from the original design in ways that compromise some of the original security guarantees.
    - wglb 2y ago
      Can you illustrate how workarounds to passkeys are being actively implemented?
      - 2y ago

acdha 2y ago

> passkeys stored in a password manager aren't any more secure in practical terms than random passwords stored in a password manager. This isn’t true, and that’s where your confusion comes in. Passkeys cannot be phished because the protocol includes the server name and does not expose the key to the remote server. The past decade of U2F/FIDO/WebAuth deployment has used that as the marquee selling point because it’s a very common exploit which cannot easily be prevented with traditional passwords and MFA.

afiori 2y ago
This ignores that most password managers check domains/origins the same way browsers do. the only difference is maybe in-app browser where the passkey integration might work more easily but even so: 1) it is still a matter of integration and/or using an actual browser 2) in-app browsers are inherently insecure anyway (at least on android)
- acdha 2y ago
  > This ignores that most password managers check domains/origins the same way browsers do. No, it doesn’t. Most password managers allow you to fill passwords for other domains and all of them allow copy-paste. The people who support those users know that phishers can convince people to do that which is why they’re encouraging adoption of WebAuthn.
- deleted 2y ago
  [deleted]

7952 2y ago

That assumes the recovery mechanism is definitely going to be a greater risk than phishing. In a corporate setting recovery could require intervention from IT support if alternative methods don't exist. That adds obscurity and natural rate limiting. Where as phishing could be as simple as a fake login page. Another factor here is the number of logins that a user is required to perform. Anecdotally this seems much higher in a corporate setting than personal. I might login to Microsoft SSO 15+ times per day for different services. Signing in to apps on my phone is rare.