6 ms·

I truly don't see the advantage of passkeys over a password manager like bitwarden, with random passwords.

bryantwolf 8mo ago
The advantage is that the password never leave the device. It has a public key and signs challenges with the private key but nothing sensitive goes over the wire on every login
- valenterry 8mo ago
  It should be noted that that is not an inherential advantage of passkeys over passwords. It is possible to achieve the same with passwords, e.g. by using a hash-cascade.
  - mi_lk 8mo ago
    is it fair to say all passkey implementations have this advantage while only some password implementations can match?
    - simoncion 8mo ago
      It is absolutely unfair to say it. Just like passwords stored in a password manager, passkeys can be copied out of the device for safekeeping. Because you can copy them out, a user can be induced to give them to someone. I saw passkey boosters go very, very rapidly from "Passkeys are immune to phishing!" to "Passkeys are phishing resistant!" when lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around.
      - lxgr 8mo ago
        > passkeys can be copied out of the device for safekeeping You can't copy them out on at least the iOS, Android, and (to my knowledge) Windows default implementations. > lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around. Millions of people use them without being able to move them around in the way you describe.
        simoncion 8mo ago
        > You can't copy them out on at least the iOS, Android, and (to my knowledge) Windows default implementations. Pardon? The official support docs disagree with you [0][1][2]. They absolutely leave the device. Other passkey managers let them leave the device in a way that you control, but even the default ones copy them off the system they were created on. [0] <https://support.google.com/accounts/answer/6197437?hl=en&co=GENIE.Platform%3DAndroid https://support.google.com/accounts/answer/6197437?hl=en&co=...> [1] <https://support.apple.com/guide/iphone/passwords-devices-iph82d6721b2/ios https://support.apple.com/guide/iphone/passwords-devices-iph...> [2] Examine the "Can I use passkeys across multiple devices?" Q and its A here: <https://support.microsoft.com/en-us/windows/passkeys-frequently-asked-questions-faq-0782c301-4b25-4a26-b7fd-3a7637d5fdd3 https://support.microsoft.com/en-us/windows/passkeys-frequen...>
        lxgr 8mo ago
        Yes, they're synchronized, but I wouldn't call that "copying them out", as that to me implies somehow getting access to the raw private key or root secret bytes. Both Apple and Google have pretty elaborate ceremonies for adding a new device to an existing account in a way that synchronizes over passkeys.
        simoncion 8mo ago
        > ...as that to me implies somehow getting access to the raw private key or root secret bytes. When passkeys were first introduced, they were 100% stuck to the device that they were created. There was absolutely no real way to copy them off. This is when proponents were -correctly- making the claim that they were immune to phishing. When lots of users (who -notably- were not supported by whole-ass IT departments who set up and run systems that handle provisioning and enrolling new devices) started using passkeys, the correctness of the thing that many non-boosters were screaming ("You have to have a way to back these up and move them between devices!") became abundantly clear. Passkeys became something that could be copied off of devices, and proponents -correctly- switched to the claim "Passkeys are phishing resistant". Once things switched around so that passkeys were no longer stuck on a single device, third-party managers got the ability to manage and copy passkeys. [0] Hopefully it's now clear that the shift from "they never leave the device" to "they do leave the device" (and the consequences of this change) is what I'm talking about. [0] At least, they will for the next five, ten years until the big players decide that it's okay to use attestation to lock them out to "enhance security".
      - fc417fc802 8mo ago
        That qualifies as "immune to phishing" as far as I'm concerned. No reasonable person using a reasonable implementation will ever be successfully victimized in that manner. We need to stop pretending that padded cells for the criminally incompetent are a desirable design target. If you are too stupid to realize that you are being taken for a ride when asked to go through a manual export process and fork over sensitive information (in this case your passkeys) to a third party then you have no business managing sensitive information to begin with. Such people should not have online accounts. We should not design technology to accommodate that level of incompetence. If you can't stop driving your car into pedestrians in crosswalks you lose your license. If you can't stop handing over your bank account number to strangers who call you on the phone you lose all of your money. If you eat rotten food you get sick and possibly die. If you hop a fence and proceed to fall off of the cliff behind it you will most likely perish. To some extent the world inherently has sharp edges and we need to stop pretending that it doesn't because when we do that it makes the world a worse place.
  - lxgr 8mo ago
    Sure, but then you still need a protocol between user agent and website. If you just do this in Javascript, you're not protected against phishing sites just forwarding the password entered directly. Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain https://github.com/lxgr/brainchain
    - valenterry 8mo ago
      > Sure, but then you still need a protocol between user agent and website. Yes of course. Just like you do for passkeys. > Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain https://github.com/lxgr/brainchain No, not quite. It's written on there: > "Login" with your passphrase, and you can create non-discoverable WebAuthN credentials (don't call them passkeys, but definitely be reminded of them) at ~all~ some websites supporting them (...) That's the thing: with passwords, a website/app cannot prevent you from controlling the password yourself. With passkeys and attestation it can.
      - lxgr 8mo ago
        But attestation for passkeys is dead. Neither Apple's, nor Google's implementation (with negligible exceptions) support it anymore, so any site demanding attestation will immediately disqualify > 99% of all potential users. Some still might, e.g. for corporate or high security contexts, but I don't think it'll become a mass-adopted thing if things don't somehow drastically change course.
        valenterry 8mo ago
        It's still in the standard. They could remove it, but they don't, so from my perspective it's just like how Google wasn't evil. Until they decided otherwise.
        lxgr 8mo ago
        > It's still in the standard. Yes, because hardware authenticators (like Yubikeys) still commonly support it, and it makes sense there. I guess they could add an explicit remark like "synchronized credentials must not support attestation", and given the amount of FUD this regularly seems to generate I'd appreciate that. But attestation semantics seem to be governed more by FIDO than the W3C, so putting that in the WebAuthN spec would be a bit awkward, I think.
pibaker 8mo ago
The main benefit is you will never put your passkey on a phishing site. Password managers provide some protections against it because if they do not work automatically on a website you know something is fishy, but sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste (or even type, if pasting is disabled) the password. The problem is whether or not the benefit outweighs the additional risks introduced — losing account access when you lose a device, furthering device lock down, difficulty transferring the passkey between devices, UX degradation due to bad implementation. In my opinion the answer is no and I am sticking with my passwords.
- TurboSkyline 8mo ago
  > sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste (or even type, if pasting is disabled) the password. Unfortunately, it’s exactly those websites that I think would be unlikely to support passkeys at all.
- encrypted_bird 8mo ago
  > but sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste Exactly this. I use KeePassXC and the number of sites where auto-input doesn't work even if the URL is 100% correct in the entry properties is _frustratingly_ high.
red_admiral 8mo ago
They're more accessible to people who don't understand computer security?
UltraSane 8mo ago
The main advantage is how strictly limited export of the passkey secret is. It is very unlikely for it to ever be phished or copied.
brikym 8mo ago
The benefit is that they aren't phishable.

The advantage is that the password never leave the device. It has a public key and signs challenges with the private key but nothing sensitive goes over the wire on every login

valenterry 8mo ago
It should be noted that that is not an inherential advantage of passkeys over passwords. It is possible to achieve the same with passwords, e.g. by using a hash-cascade.
- mi_lk 8mo ago
  is it fair to say all passkey implementations have this advantage while only some password implementations can match?
  - simoncion 8mo ago
    It is absolutely unfair to say it. Just like passwords stored in a password manager, passkeys can be copied out of the device for safekeeping. Because you can copy them out, a user can be induced to give them to someone. I saw passkey boosters go very, very rapidly from "Passkeys are immune to phishing!" to "Passkeys are phishing resistant!" when lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around.
    - lxgr 8mo ago
      > passkeys can be copied out of the device for safekeeping You can't copy them out on at least the iOS, Android, and (to my knowledge) Windows default implementations. > lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around. Millions of people use them without being able to move them around in the way you describe.
      - simoncion 8mo ago
        > You can't copy them out on at least the iOS, Android, and (to my knowledge) Windows default implementations. Pardon? The official support docs disagree with you [0][1][2]. They absolutely leave the device. Other passkey managers let them leave the device in a way that you control, but even the default ones copy them off the system they were created on. [0] <https://support.google.com/accounts/answer/6197437?hl=en&co=GENIE.Platform%3DAndroid https://support.google.com/accounts/answer/6197437?hl=en&co=...> [1] <https://support.apple.com/guide/iphone/passwords-devices-iph82d6721b2/ios https://support.apple.com/guide/iphone/passwords-devices-iph...> [2] Examine the "Can I use passkeys across multiple devices?" Q and its A here: <https://support.microsoft.com/en-us/windows/passkeys-frequently-asked-questions-faq-0782c301-4b25-4a26-b7fd-3a7637d5fdd3 https://support.microsoft.com/en-us/windows/passkeys-frequen...>
        lxgr 8mo ago
        Yes, they're synchronized, but I wouldn't call that "copying them out", as that to me implies somehow getting access to the raw private key or root secret bytes. Both Apple and Google have pretty elaborate ceremonies for adding a new device to an existing account in a way that synchronizes over passkeys.
        simoncion 8mo ago
        > ...as that to me implies somehow getting access to the raw private key or root secret bytes. When passkeys were first introduced, they were 100% stuck to the device that they were created. There was absolutely no real way to copy them off. This is when proponents were -correctly- making the claim that they were immune to phishing. When lots of users (who -notably- were not supported by whole-ass IT departments who set up and run systems that handle provisioning and enrolling new devices) started using passkeys, the correctness of the thing that many non-boosters were screaming ("You have to have a way to back these up and move them between devices!") became abundantly clear. Passkeys became something that could be copied off of devices, and proponents -correctly- switched to the claim "Passkeys are phishing resistant". Once things switched around so that passkeys were no longer stuck on a single device, third-party managers got the ability to manage and copy passkeys. [0] Hopefully it's now clear that the shift from "they never leave the device" to "they do leave the device" (and the consequences of this change) is what I'm talking about. [0] At least, they will for the next five, ten years until the big players decide that it's okay to use attestation to lock them out to "enhance security".
    - fc417fc802 8mo ago
      That qualifies as "immune to phishing" as far as I'm concerned. No reasonable person using a reasonable implementation will ever be successfully victimized in that manner. We need to stop pretending that padded cells for the criminally incompetent are a desirable design target. If you are too stupid to realize that you are being taken for a ride when asked to go through a manual export process and fork over sensitive information (in this case your passkeys) to a third party then you have no business managing sensitive information to begin with. Such people should not have online accounts. We should not design technology to accommodate that level of incompetence. If you can't stop driving your car into pedestrians in crosswalks you lose your license. If you can't stop handing over your bank account number to strangers who call you on the phone you lose all of your money. If you eat rotten food you get sick and possibly die. If you hop a fence and proceed to fall off of the cliff behind it you will most likely perish. To some extent the world inherently has sharp edges and we need to stop pretending that it doesn't because when we do that it makes the world a worse place.
- lxgr 8mo ago
  Sure, but then you still need a protocol between user agent and website. If you just do this in Javascript, you're not protected against phishing sites just forwarding the password entered directly. Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain https://github.com/lxgr/brainchain
  - valenterry 8mo ago
    > Sure, but then you still need a protocol between user agent and website. Yes of course. Just like you do for passkeys. > Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain https://github.com/lxgr/brainchain No, not quite. It's written on there: > "Login" with your passphrase, and you can create non-discoverable WebAuthN credentials (don't call them passkeys, but definitely be reminded of them) at ~all~ some websites supporting them (...) That's the thing: with passwords, a website/app cannot prevent you from controlling the password yourself. With passkeys and attestation it can.
    - lxgr 8mo ago
      But attestation for passkeys is dead. Neither Apple's, nor Google's implementation (with negligible exceptions) support it anymore, so any site demanding attestation will immediately disqualify > 99% of all potential users. Some still might, e.g. for corporate or high security contexts, but I don't think it'll become a mass-adopted thing if things don't somehow drastically change course.
      - valenterry 8mo ago
        It's still in the standard. They could remove it, but they don't, so from my perspective it's just like how Google wasn't evil. Until they decided otherwise.
        lxgr 8mo ago
        > It's still in the standard. Yes, because hardware authenticators (like Yubikeys) still commonly support it, and it makes sense there. I guess they could add an explicit remark like "synchronized credentials must not support attestation", and given the amount of FUD this regularly seems to generate I'd appreciate that. But attestation semantics seem to be governed more by FIDO than the W3C, so putting that in the WebAuthN spec would be a bit awkward, I think.

pibaker 8mo ago

The main benefit is you will never put your passkey on a phishing site. Password managers provide some protections against it because if they do not work automatically on a website you know something is fishy, but sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste (or even type, if pasting is disabled) the password. The problem is whether or not the benefit outweighs the additional risks introduced — losing account access when you lose a device, furthering device lock down, difficulty transferring the passkey between devices, UX degradation due to bad implementation. In my opinion the answer is no and I am sticking with my passwords.

TurboSkyline 8mo ago
> sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste (or even type, if pasting is disabled) the password. Unfortunately, it’s exactly those websites that I think would be unlikely to support passkeys at all.
encrypted_bird 8mo ago
> but sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste Exactly this. I use KeePassXC and the number of sites where auto-input doesn't work even if the URL is 100% correct in the entry properties is _frustratingly_ high.

red_admiral 8mo ago

They're more accessible to people who don't understand computer security?

UltraSane 8mo ago

The main advantage is how strictly limited export of the passkey secret is. It is very unlikely for it to ever be phished or copied.

brikym 8mo ago

The benefit is that they aren't phishable.