4 ms·

2 things about passkeys I wish would be fixed. 1. Passkey prompts asking if I want to use a phone or security key when I only have one (or neither!) registered

by kemotep 10mo ago

2 things about passkeys I wish would be fixed. 1. Passkey prompts asking if I want to use a phone or security key when I only have one (or neither!) registered. The UI for this gets in the way and should only ever present itself if I happen to have both kinds of devices registered. 2. Passkeys should have had the portability and flexibility that ssh keys have from the start. Making it so your grandparents can use public key cryptography and gain a significant advantage in securing their accounts in a user friendly manner should have been the priority. Seems like vendor lock-in was the goal from the start.

lapcat 10mo ago
> Seems like vendor lock-in was the goal from the start. Exactly. The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them. The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials. You can go from one passkey vendor to another, but you're always locked in to one passkey vendor or another. Any credential system that makes it impossible to write something down on a piece of paper, take it to a new computer, and login to a website is just a gateway to vendor lock-in. You can manually manage your own ssh keys but for some reason not your passkeys. As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. [EDIT: Obviously I'm talking about built-in support. I'm well aware of third-party software, so everyone can stop replying to this now, please!] You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac. The passkey vendors took some good theoretical ideas, such as site-specific credentials and public-key cryptography, and totally mangled the implementation, making it hostile to everyone except themselves.
- mroche 10mo ago
  This is obviously kicking the can down the road, but I "solve" this problem by storing passkeys in a third-party credential manager that supports them. That way I can use them on any device that I've installed the client app or browser extension on. I have this working on Fedora, macOS, Windows, and iOS. But again, kicking the can down the road.
  - deltoidmaximus 10mo ago
    Well, you can until they use the attestation feature to block your passkey manager implementation.
- pastel8739 10mo ago
  > The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials. I’ll accept that the attestation parts of the protocol may have had some ulterior motives (though I’m skeptical), but not having to reveal your credential to the verifying party is the entire benefit of passkeys and hugely important to stop phishing. I think it’s disingenuous to argue that this is somehow unnecessary.
  - lapcat 10mo ago
    > not having to reveal your credential to the verifying party is the entire benefit of passkeys I think you misunderstood what I was talking about. The credential exchange protocol is for exporting passkeys from one credentials manager and importing them into another credentials manager. It has nothing to do with the relying party.
    - pastel8739 10mo ago
      Oh, indeed, sorry. Yes I thought you were talking about the authentication process.
- peanut-walrus 10mo ago
  It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support. For the general public, they already rely on either Google or Apple for pretty much all of their digital life. Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
  - lapcat 10mo ago
    > It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support. I don't want to use a Yubikey. It's a pain in the butt. I just want to use my Mac, with no more damn dongles. Keepass is a vendor, and one who doesn't even have a Safari extension. > Nothing wrong with extending this to passkeys, it's convenient and makes sense for them. I didn't say there was anything wrong with extending this to passkeys. The problem is the lock-in, e.g., Safari requires iCloud keychain for passkeys, but not for passwords. And there is no plaintext export/import, unlike with passwords. Nobody can convince me that passkeys are good when I buy a Mac and use the built-in Safari but can't even use passkeys to log in to websites unless I give my passkeys to a cloud sync service or have to install some third-party "solution" (for a problem that should not exist in the first place). That experience is so much worse than passwords.
    - peanut-walrus 10mo ago
      So don't use software that forces lock-in (Safari)? Sounds like a you problem.
      - lapcat 10mo ago
        > So don't use software that forces lock-in (Safari)? Sounds like a you problem. No, this is a passkeys problem. Safari does not force lock-in of passwords. Why in the world would I want to ditch my web browser just to use passkeys? I'd rather ditch passkeys.
        10mo ago
- jmsgwd 10mo ago
  > passkeys in Safari requires iCloud Keychain This is not true - browsers including Safari support passkeys managed by third-party password managers. I'm using 1Password with browser extensions for Safari and Chrome on macOS and iOS and it works seamlessly with my passkeys, which are not stored in iCloud Keychain. > you're always locked in to one passkey vendor or another. This will change: https://1password.com/blog/fido-alliance-import-export-passkeys-draft-specs https://1password.com/blog/fido-alliance-import-export-passk...
  - lapcat 10mo ago
    > This is not true - Safari also supports passkeys managed by third-party password managers. I think you know what I meant and are just being pedantic here for no good reason. Do you think I'm unaware of 1Password? I don't want to use 1Password any more than I want to use iCloud Keychain. Technically, pendantically, Safari "supports" anything that third-party Safari extensions support. I'm a Safari extension developer myself. But this is totally different from how Safari supports the use of passwords, which is all built in, requires no third-party software, can be local-only, allows plaintext export/import, etc. > This will change: https://1password.com/blog/fido-alliance-import-export-passkeys-draft-specs https://1password.com/blog/fido-alliance-import-export-passk... This is literally what I meant by the so-called "secure credential exchange" in my previous comment.
    - jmsgwd 10mo ago
      OK I see what you mean. Having the ability to switch between vendors but not the ability to export your data locally (e.g. as plaintext keys) is a new meaning of "vendor lock-in" I hadn't considered before.
      - lapcat 10mo ago
        Yes. User freedom is not all-or-nothing. There are degrees, and the tech companies are coming up with fiendish new ways to lock away your data from you. So in the case of passkeys, you can technically move your data between vendors, though that can be quite inconvenient as the submitted article mentions, but nonetheless every vendor locks away your data from you, and most vendors have a financial incentive to keep your data away from you, so that you have to pay for the services.
- happyopossum 10mo ago
  > what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain Completely untrue, Safari on both Mac and iOS supports third-party password managers for both traditional passwords and passkeys.
  - lapcat 10mo ago
    You're repeating yourself and also way too many pedantic comments here: https://news.ycombinator.com/item?id=46304159 https://news.ycombinator.com/item?id=46304159
- timmyc123 10mo ago
  > The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them. Care to cite this statement? > As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac. You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
  - Dagonfly 10mo ago
    Quoting your comments on github [0] >> There is no passkey certification process > This is currently being defined and is almost complete. >> no signed stamp of approval from on high > see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers. Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID? [0] https://github.com/keepassxreboot/keepassxc/issues/10406#issuecomment-1994313373 https://github.com/keepassxreboot/keepassxc/issues/10406#iss...
    - timmyc123 10mo ago
      Unclear how this quoted comment relates to what I was replying to (which was about exporting / backing up your credentials). But I'll respond. > Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID? If a website were to block your custom software's AAGUID for some reason, you can change your AAGUID. AAGUIDs in the consumer passkey ecosystem are used to name your credential manager in account settings so you remember where you saved your passkey.
      - Dagonfly 10mo ago
nine_k 10mo ago
Passkeys seem to be the best solution for users whose technical chops cannot be trusted, and who are also gullible enough to be a scam / social engineering target. Which, to my mind, describes a large enough chunk of audience of most popular services. A tech-savvy relative of such a user should help them generate rescue codes, write them on a piece of paper, and store them along with all other important documents. Ideally the paper should also read: "Call me before using any of these codes! <phone number>."
- calvinmorrison 10mo ago
  it's just a further step whittling away of browsers being a "user client". a key based approach is great. Knowing (the passphrase) and Having (the key) is a good way to authenticate.
  - nine_k 10mo ago
    A "user agent", I suppose. The agent could identify you to online services, and it does. Remembering and typing a passphrase is often too hard (or "too hard") for some users. A passkey is better than a password like 123456 or name + year of birth, or other such "easy to remember" passwords people invent to avoid remembering a passphrase. Especially if you have a hundred logins. A passkey basically offloads user identification to the OS (especially a mobile OS). It should not be the only way to identify though. An ssh-style key + password is fine. A username + password + TOTP should also be fine. But 99.9% of passwords should be in a password manager anyway. Rescue codes should always be generated and written down when activating a passkey or similar, but this requires certain discipline, some feeling of importance. And many web sites that require registration don't seem important for users, especially one-time users. What makes sense for your Google account, or your bank account, feels like too much ceremony for a low-stakes login like a random online store; losing a login to it does not feel like a big loss to many people.
n8cpdx 10mo ago
On Mac with the security key you can just press the button on the security key before choosing a path. It only looks like a required extra step but in practice it is optional.
Jiro 10mo ago
>The UI for this gets in the way and should only ever present itself if I happen to have both kinds of devices registered. I disagree. It is very annoying when some service fails to show an option on the grounds that I can't use it. It makes it difficult to resolve problems. If the option is just missing, I have no way to tell whether the company doesn't provide the option, whether the company made some sort of mistake (they can't provide an email option because they lost my email), whether I made a mistake, or whether the company just has a bad UI that tries to hide the option. And don't forget the situation where I tried to google online for some help in using the UI, I found a 6 month old Reddit post showing the option, and I can't figure out if the company changed the UI in the past six months. They should show it greyed out with a note "no key of this type registered".
- kemotep 10mo ago
  That’s fair. I just meant that during logon, it is annoying to have to click through an additional prompt that doesn’t apply. But I can see where if there was an issue showing what all the options could be and if they are enabled or unavailable or you want to set it up, would be more beneficial than not.

by kemotep 10mo ago

lapcat 10mo ago

> Seems like vendor lock-in was the goal from the start. Exactly. The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them. The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials. You can go from one passkey vendor to another, but you're always locked in to one passkey vendor or another. Any credential system that makes it impossible to write something down on a piece of paper, take it to a new computer, and login to a website is just a gateway to vendor lock-in. You can manually manage your own ssh keys but for some reason not your passkeys. As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. [EDIT: Obviously I'm talking about built-in support. I'm well aware of third-party software, so everyone can stop replying to this now, please!] You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac. The passkey vendors took some good theoretical ideas, such as site-specific credentials and public-key cryptography, and totally mangled the implementation, making it hostile to everyone except themselves.

mroche 10mo ago
This is obviously kicking the can down the road, but I "solve" this problem by storing passkeys in a third-party credential manager that supports them. That way I can use them on any device that I've installed the client app or browser extension on. I have this working on Fedora, macOS, Windows, and iOS. But again, kicking the can down the road.
- deltoidmaximus 10mo ago
  Well, you can until they use the attestation feature to block your passkey manager implementation.
pastel8739 10mo ago
> The purpose of the so-called "secure credential exchange" is once again to prevent you from directly accessing your credentials. I’ll accept that the attestation parts of the protocol may have had some ulterior motives (though I’m skeptical), but not having to reveal your credential to the verifying party is the entire benefit of passkeys and hugely important to stop phishing. I think it’s disingenuous to argue that this is somehow unnecessary.
- lapcat 10mo ago
  > not having to reveal your credential to the verifying party is the entire benefit of passkeys I think you misunderstood what I was talking about. The credential exchange protocol is for exporting passkeys from one credentials manager and importing them into another credentials manager. It has nothing to do with the relying party.
  - pastel8739 10mo ago
    Oh, indeed, sorry. Yes I thought you were talking about the authentication process.
peanut-walrus 10mo ago
It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support. For the general public, they already rely on either Google or Apple for pretty much all of their digital life. Nothing wrong with extending this to passkeys, it's convenient and makes sense for them.
- lapcat 10mo ago
  > It's an open protocol, you don't need to use any of the vendors. My Yubikey is a "passkey", so is my Flipper Zero. Keepass provides passkey support. I don't want to use a Yubikey. It's a pain in the butt. I just want to use my Mac, with no more damn dongles. Keepass is a vendor, and one who doesn't even have a Safari extension. > Nothing wrong with extending this to passkeys, it's convenient and makes sense for them. I didn't say there was anything wrong with extending this to passkeys. The problem is the lock-in, e.g., Safari requires iCloud keychain for passkeys, but not for passwords. And there is no plaintext export/import, unlike with passwords. Nobody can convince me that passkeys are good when I buy a Mac and use the built-in Safari but can't even use passkeys to log in to websites unless I give my passkeys to a cloud sync service or have to install some third-party "solution" (for a problem that should not exist in the first place). That experience is so much worse than passwords.
  - peanut-walrus 10mo ago
    So don't use software that forces lock-in (Safari)? Sounds like a you problem.
    - lapcat 10mo ago
      > So don't use software that forces lock-in (Safari)? Sounds like a you problem. No, this is a passkeys problem. Safari does not force lock-in of passwords. Why in the world would I want to ditch my web browser just to use passkeys? I'd rather ditch passkeys.
      - 10mo ago
jmsgwd 10mo ago
> passkeys in Safari requires iCloud Keychain This is not true - browsers including Safari support passkeys managed by third-party password managers. I'm using 1Password with browser extensions for Safari and Chrome on macOS and iOS and it works seamlessly with my passkeys, which are not stored in iCloud Keychain. > you're always locked in to one passkey vendor or another. This will change: https://1password.com/blog/fido-alliance-import-export-passkeys-draft-specs https://1password.com/blog/fido-alliance-import-export-passk...
- lapcat 10mo ago
  > This is not true - Safari also supports passkeys managed by third-party password managers. I think you know what I meant and are just being pedantic here for no good reason. Do you think I'm unaware of 1Password? I don't want to use 1Password any more than I want to use iCloud Keychain. Technically, pendantically, Safari "supports" anything that third-party Safari extensions support. I'm a Safari extension developer myself. But this is totally different from how Safari supports the use of passwords, which is all built in, requires no third-party software, can be local-only, allows plaintext export/import, etc. > This will change: https://1password.com/blog/fido-alliance-import-export-passkeys-draft-specs https://1password.com/blog/fido-alliance-import-export-passk... This is literally what I meant by the so-called "secure credential exchange" in my previous comment.
  - jmsgwd 10mo ago
    OK I see what you mean. Having the ability to switch between vendors but not the ability to export your data locally (e.g. as plaintext keys) is a new meaning of "vendor lock-in" I hadn't considered before.
    - lapcat 10mo ago
      Yes. User freedom is not all-or-nothing. There are degrees, and the tech companies are coming up with fiendish new ways to lock away your data from you. So in the case of passkeys, you can technically move your data between vendors, though that can be quite inconvenient as the submitted article mentions, but nonetheless every vendor locks away your data from you, and most vendors have a financial incentive to keep your data away from you, so that you have to pay for the services.
happyopossum 10mo ago
> what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain Completely untrue, Safari on both Mac and iOS supports third-party password managers for both traditional passwords and passkeys.
- lapcat 10mo ago
  You're repeating yourself and also way too many pedantic comments here: https://news.ycombinator.com/item?id=46304159 https://news.ycombinator.com/item?id=46304159
timmyc123 10mo ago
> The passkey vendors state that the goal was to make phishing not just difficult but impossible. This means plaintext access to your credentials is forbidden forever, regardless of your level of expertise, and regardless of the complexity of the process to export/import them. Care to cite this statement? > As an Apple Mac user, what annoys me the most is that the use of passkeys in Safari requires iCloud Keychain, which of course requires iCloud and an Apple Account. You can't do local-only passkeys, not even if you take responsibility for backing up your own Mac. You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
- Dagonfly 10mo ago
  Quoting your comments on github [0] >> There is no passkey certification process > This is currently being defined and is almost complete. >> no signed stamp of approval from on high > see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers. Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID? [0] https://github.com/keepassxreboot/keepassxc/issues/10406#issuecomment-1994313373 https://github.com/keepassxreboot/keepassxc/issues/10406#iss...
  - timmyc123 10mo ago
    Unclear how this quoted comment relates to what I was replying to (which was about exporting / backing up your credentials). But I'll respond. > Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID? If a website were to block your custom software's AAGUID for some reason, you can change your AAGUID. AAGUIDs in the consumer passkey ecosystem are used to name your credential manager in account settings so you remember where you saved your passkey.
    - Dagonfly 10mo ago

nine_k 10mo ago

Passkeys seem to be the best solution for users whose technical chops cannot be trusted, and who are also gullible enough to be a scam / social engineering target. Which, to my mind, describes a large enough chunk of audience of most popular services. A tech-savvy relative of such a user should help them generate rescue codes, write them on a piece of paper, and store them along with all other important documents. Ideally the paper should also read: "Call me before using any of these codes! <phone number>."

calvinmorrison 10mo ago
it's just a further step whittling away of browsers being a "user client". a key based approach is great. Knowing (the passphrase) and Having (the key) is a good way to authenticate.
- nine_k 10mo ago
  A "user agent", I suppose. The agent could identify you to online services, and it does. Remembering and typing a passphrase is often too hard (or "too hard") for some users. A passkey is better than a password like 123456 or name + year of birth, or other such "easy to remember" passwords people invent to avoid remembering a passphrase. Especially if you have a hundred logins. A passkey basically offloads user identification to the OS (especially a mobile OS). It should not be the only way to identify though. An ssh-style key + password is fine. A username + password + TOTP should also be fine. But 99.9% of passwords should be in a password manager anyway. Rescue codes should always be generated and written down when activating a passkey or similar, but this requires certain discipline, some feeling of importance. And many web sites that require registration don't seem important for users, especially one-time users. What makes sense for your Google account, or your bank account, feels like too much ceremony for a low-stakes login like a random online store; losing a login to it does not feel like a big loss to many people.

n8cpdx 10mo ago

On Mac with the security key you can just press the button on the security key before choosing a path. It only looks like a required extra step but in practice it is optional.

Jiro 10mo ago

>The UI for this gets in the way and should only ever present itself if I happen to have both kinds of devices registered. I disagree. It is very annoying when some service fails to show an option on the grounds that I can't use it. It makes it difficult to resolve problems. If the option is just missing, I have no way to tell whether the company doesn't provide the option, whether the company made some sort of mistake (they can't provide an email option because they lost my email), whether I made a mistake, or whether the company just has a bad UI that tries to hide the option. And don't forget the situation where I tried to google online for some help in using the UI, I found a 6 month old Reddit post showing the option, and I can't figure out if the company changed the UI in the past six months. They should show it greyed out with a note "no key of this type registered".

kemotep 10mo ago
That’s fair. I just meant that during logon, it is annoying to have to click through an additional prompt that doesn’t apply. But I can see where if there was an issue showing what all the options could be and if they are enabled or unavailable or you want to set it up, would be more beneficial than not.