3 ms·

Lots of criticism in the article, some of it valid, none of it constructive. Sure, there's UX problems as we're still trying to figure out what good looks like

by growse 2y ago

Lots of criticism in the article, some of it valid, none of it constructive. Sure, there's UX problems as we're still trying to figure out what good looks like here. But in the absence of specific, concrete suggestions about how we improve usability for unphishable credentials, it seems that passkeys are a pretty good go. Perfect? No. Better than passwords? Undoubtedly.

saagarjha 2y ago
The point of the article is that they are not actually better than passwords in a lot of ways that people actually want them to be better.
- growse 2y ago
  One of the primary, explicit design goals of webauthn is that they're not phishable. Passwords are phishable. What are the other ways that people want passkeys to be better?
  - saagarjha 2y ago
    They want to share them across devices, sometimes even devices made by different vendors. They want to hand a passkey to a family member or friend. They want to not be concerned they will lose the passkey if the device they are on is lost. They want to understand what the passkey is actually doing for them when they log in, rather than it sometimes being both the username and password, sometimes just replacing the password, and sometimes becoming a sort of weird second factor thing. They want to know how they can change their passkey. The rollout of passkeys leaves a lot to be desired.
    - growse 2y ago
      I don't disagree with you about the UX. It could be better. It could be worse. What's your proposal on what a better UX might look like (along with getting everyone to adopt it)? > They want to share them across devices I do this today on Bitwarden, Apple users do this today with Keychain. Who's the "they" here? > sometimes even devices made by different vendors. > they want to hand a passkey to a family member or friend ..... Why? What's the use case here? Tying a credential to a single identity (and therefore, human) is another explicit design goal of webauthn. I seem to remember the original proposal was that locking a private key to a device in an unextractable, un-copyable way was an explicit benefit - if it can't be exported, then it can't be stolen/copied without the device also being stolen. This was softened with the purpose of allowing syncing amongst devices that already have a good story on sharing sensitive data, but this mechanism does not exist generically. There is no standard way, right now, that my iPad and Pixel device can share a private, sensitive piece of information without the help of a 3rd-party syncing provider. Without that, cross-platform credential sharing can't exist out of the box by default.
      - jampekka 2y ago
        > Why? What's the use case here? Tech support for relatives. Accessing accounts from different machines. Joint access for family members and friends. Emergency access when a phone or dongle breaks down or gets lost. Tightly device-tied authentication mechanisms are fundamentally out of touch with the real world.
      - saagarjha 2y ago
        I mean I like them in theory but they should just be passwords you can't easily copy from your password manager. You can export them, which I'm sure someone will trick people into doing, but that's somewhat different from being tricked into pasting ul0vek1tt3ns into legitimateapple-support.info. As for sharing passkeys: never grabbed a friend's Netflix account? Had to log into your kid's college application page to confirm your income? Sign up for an appointment for your elderly parents? This is a thing people actually need to do, and value more than avoiding being phished. Believe me. It's not worth abandoning for "ok there is a possibility someone can be phished if the key material isn't protected by a hardware key and three layers of DRM".
      - michaelt 2y ago
        > What's your proposal on what a better UX might look like (along with getting everyone to adopt it)? The current passkey implementation is: Your google/apple/microsoft cloud account lets you log into websites without a password, using a 'keyring' of 'passkeys' But we already had countless websites with a "log in with google" button, for users who want to authenticate using their cloud account, and skip entering a password. So they could have just kept that... exactly how it was?
        rawgabbit 2y ago
        The analogy is similar to swiping your credit card versus using Apple Pay. With “login using Google/Apple”, you are submitting the username and password which could potentially be harvested by malware or a key logger. With passkey/Apple Pay, you are submitting a one time token that has no value in the Dark Web.
      - robertlagrant 2y ago
  - eadmund 2y ago
    > Passwords are phishable. Passwords auto-filled by a browser extension are not phishable.
    - growse 2y ago
      What stops the user pasting their password out of their password manager into a random evil site? Auto-fill isn't infallible. This isn't a controversial topic, the data is pretty unambiguous. If you give humans a secret they can put in their clipboard and train them to enter it into text boxes, some fraction of them will send their credentials to the wrong people.
      - saagarjha 2y ago
        Maybe we don’t actually need perfect solutions.
        robertlagrant 2y ago
        "Maybe" is not a viable justification for a position.
        saagarjha 2y ago
        I am being flippant. Obviously my position is that perfection is a harmful thing to strive for.
        growse 2y ago
        We're not aiming for "perfect", we're just trying to make some progress on the phishing problem. The irony here is that many of the complaints in this thread seem to be complaining about how imperfect passkeys are. No-one disagrees that they're imperfect!
        saagarjha 2y ago
        Yes, and passkeys generally help. But your concern upthread was that any mechanism that lets users share or export passkeys (or other authentication material, such as passwords) allows a user to be phished. Basically, the very fact that this is somehow accessible means a user can be tricked into disclosing it. This is correct, but my point is that perfection in that area necessarily means that a lot of things that are useful (some of which have been shared in sibling threads) are now impossible. So we should not actually aim for perfection on phishing, but just to make improvements where possible.
  - magicalhippo 2y ago
    I just wanted a standard data exchange interface between my browser and my preferred password manager, so that my password manager didn't have to try to emulate a human being typing or pasting a password. That way the password would only "live" in the password manager and wouldn't need to even be easily visible to me. I almost never care what the password actually is. But it would still be a password so compatible with most sites as-is, and easily backed up and restored on new devices.
ghjfrdghibt 2y ago
I don't think it's the responsibility of the author to make any constructive input to the passkey problem. The point of the article is to show the valid shortcomings of this technology that a bunch of companies are attempting to force on users. My workaround to allow passkeys to be reasonably usable is to use my password manager, just like the author of this article. This makes passkeys essentially the same as passwords. At no point am I tying account access to a device, or series of devices, as this is ridiculous and unusable. Passkeys as encouraged by the big companies are all about vendor lock-in than security.
- growse 2y ago
  > I don't think it's the responsibility of the author to make any constructive input to the passkey problem. Oh, it's not their responsibility, sure. But moaning about the UX without considering the trade-offs and decisions that got us to this point isn't very useful. Passkeys are badly implemented on some sites. So let's fix that. > This makes passkeys essentially the same as passwords. Passkeys in a password manager are fundamentally different to passwords. Try copying the passkey private key into your clipboard from your password manager. > Passkeys as encouraged by the big companies are all about vendor lock-in than security. The fact they prevent phishing is just a useful side-effect? This is veering into conspiracy theory territory.
  - simoncion 2y ago
    > Passkeys are badly implemented on some sites. So let's fix that. It's not the obligation of the Ars writer to fix that. It is their obligation to give the system a solid try and report honestly about what did and did not work. > Try copying the passkey private key into your clipboard from your password manager. Yeah, something that's roughly equivalent to that is coming. Used to be that you were not permitted to export key material. Now you can. This will erode further as real-world use continues. Oh, wait. It looks like secured-only-by-a-password access to passkey private key material is already possible, today: "Q: Are stored passkeys included in Bitwarden imports and exports?" "A: Passkeys are included in .json exports from Bitwarden. The ability to transfer your passkeys to or from another passkey provider is planned for a future release." Quotes are via the "Passkey Management FAQ" section of this page: <https://bitwarden.com/help/storing-passkeys/ https://bitwarden.com/help/storing-passkeys/>

by growse 2y ago

saagarjha 2y ago

The point of the article is that they are not actually better than passwords in a lot of ways that people actually want them to be better.

growse 2y ago
One of the primary, explicit design goals of webauthn is that they're not phishable. Passwords are phishable. What are the other ways that people want passkeys to be better?
- saagarjha 2y ago
  They want to share them across devices, sometimes even devices made by different vendors. They want to hand a passkey to a family member or friend. They want to not be concerned they will lose the passkey if the device they are on is lost. They want to understand what the passkey is actually doing for them when they log in, rather than it sometimes being both the username and password, sometimes just replacing the password, and sometimes becoming a sort of weird second factor thing. They want to know how they can change their passkey. The rollout of passkeys leaves a lot to be desired.
  - growse 2y ago
    I don't disagree with you about the UX. It could be better. It could be worse. What's your proposal on what a better UX might look like (along with getting everyone to adopt it)? > They want to share them across devices I do this today on Bitwarden, Apple users do this today with Keychain. Who's the "they" here? > sometimes even devices made by different vendors. > they want to hand a passkey to a family member or friend ..... Why? What's the use case here? Tying a credential to a single identity (and therefore, human) is another explicit design goal of webauthn. I seem to remember the original proposal was that locking a private key to a device in an unextractable, un-copyable way was an explicit benefit - if it can't be exported, then it can't be stolen/copied without the device also being stolen. This was softened with the purpose of allowing syncing amongst devices that already have a good story on sharing sensitive data, but this mechanism does not exist generically. There is no standard way, right now, that my iPad and Pixel device can share a private, sensitive piece of information without the help of a 3rd-party syncing provider. Without that, cross-platform credential sharing can't exist out of the box by default.
    - jampekka 2y ago
      > Why? What's the use case here? Tech support for relatives. Accessing accounts from different machines. Joint access for family members and friends. Emergency access when a phone or dongle breaks down or gets lost. Tightly device-tied authentication mechanisms are fundamentally out of touch with the real world.
    - saagarjha 2y ago
      I mean I like them in theory but they should just be passwords you can't easily copy from your password manager. You can export them, which I'm sure someone will trick people into doing, but that's somewhat different from being tricked into pasting ul0vek1tt3ns into legitimateapple-support.info. As for sharing passkeys: never grabbed a friend's Netflix account? Had to log into your kid's college application page to confirm your income? Sign up for an appointment for your elderly parents? This is a thing people actually need to do, and value more than avoiding being phished. Believe me. It's not worth abandoning for "ok there is a possibility someone can be phished if the key material isn't protected by a hardware key and three layers of DRM".
    - michaelt 2y ago
      > What's your proposal on what a better UX might look like (along with getting everyone to adopt it)? The current passkey implementation is: Your google/apple/microsoft cloud account lets you log into websites without a password, using a 'keyring' of 'passkeys' But we already had countless websites with a "log in with google" button, for users who want to authenticate using their cloud account, and skip entering a password. So they could have just kept that... exactly how it was?
      - rawgabbit 2y ago
        The analogy is similar to swiping your credit card versus using Apple Pay. With “login using Google/Apple”, you are submitting the username and password which could potentially be harvested by malware or a key logger. With passkey/Apple Pay, you are submitting a one time token that has no value in the Dark Web.
    - robertlagrant 2y ago
- eadmund 2y ago
  > Passwords are phishable. Passwords auto-filled by a browser extension are not phishable.
  - growse 2y ago
    What stops the user pasting their password out of their password manager into a random evil site? Auto-fill isn't infallible. This isn't a controversial topic, the data is pretty unambiguous. If you give humans a secret they can put in their clipboard and train them to enter it into text boxes, some fraction of them will send their credentials to the wrong people.
    - saagarjha 2y ago
      Maybe we don’t actually need perfect solutions.
      - robertlagrant 2y ago
        "Maybe" is not a viable justification for a position.
        saagarjha 2y ago
        I am being flippant. Obviously my position is that perfection is a harmful thing to strive for.
        growse 2y ago
        We're not aiming for "perfect", we're just trying to make some progress on the phishing problem. The irony here is that many of the complaints in this thread seem to be complaining about how imperfect passkeys are. No-one disagrees that they're imperfect!
        saagarjha 2y ago
        Yes, and passkeys generally help. But your concern upthread was that any mechanism that lets users share or export passkeys (or other authentication material, such as passwords) allows a user to be phished. Basically, the very fact that this is somehow accessible means a user can be tricked into disclosing it. This is correct, but my point is that perfection in that area necessarily means that a lot of things that are useful (some of which have been shared in sibling threads) are now impossible. So we should not actually aim for perfection on phishing, but just to make improvements where possible.
- magicalhippo 2y ago
  I just wanted a standard data exchange interface between my browser and my preferred password manager, so that my password manager didn't have to try to emulate a human being typing or pasting a password. That way the password would only "live" in the password manager and wouldn't need to even be easily visible to me. I almost never care what the password actually is. But it would still be a password so compatible with most sites as-is, and easily backed up and restored on new devices.

ghjfrdghibt 2y ago

I don't think it's the responsibility of the author to make any constructive input to the passkey problem. The point of the article is to show the valid shortcomings of this technology that a bunch of companies are attempting to force on users. My workaround to allow passkeys to be reasonably usable is to use my password manager, just like the author of this article. This makes passkeys essentially the same as passwords. At no point am I tying account access to a device, or series of devices, as this is ridiculous and unusable. Passkeys as encouraged by the big companies are all about vendor lock-in than security.

growse 2y ago
> I don't think it's the responsibility of the author to make any constructive input to the passkey problem. Oh, it's not their responsibility, sure. But moaning about the UX without considering the trade-offs and decisions that got us to this point isn't very useful. Passkeys are badly implemented on some sites. So let's fix that. > This makes passkeys essentially the same as passwords. Passkeys in a password manager are fundamentally different to passwords. Try copying the passkey private key into your clipboard from your password manager. > Passkeys as encouraged by the big companies are all about vendor lock-in than security. The fact they prevent phishing is just a useful side-effect? This is veering into conspiracy theory territory.
- simoncion 2y ago
  > Passkeys are badly implemented on some sites. So let's fix that. It's not the obligation of the Ars writer to fix that. It is their obligation to give the system a solid try and report honestly about what did and did not work. > Try copying the passkey private key into your clipboard from your password manager. Yeah, something that's roughly equivalent to that is coming. Used to be that you were not permitted to export key material. Now you can. This will erode further as real-world use continues. Oh, wait. It looks like secured-only-by-a-password access to passkey private key material is already possible, today: "Q: Are stored passkeys included in Bitwarden imports and exports?" "A: Passkeys are included in .json exports from Bitwarden. The ability to transfer your passkeys to or from another passkey provider is planned for a future release." Quotes are via the "Passkey Management FAQ" section of this page: <https://bitwarden.com/help/storing-passkeys/ https://bitwarden.com/help/storing-passkeys/>