| > 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. |
| |
| ▲ | jmsgwd 5 days ago | parent | next [-] | | > 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-passk... | | |
| ▲ | lapcat 5 days ago | parent [-] | | > 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-passk... This is literally what I meant by the so-called "secure credential exchange" in my previous comment. | | |
| ▲ | unsnap_biceps 5 days ago | parent | next [-] | | Reading the cfx spec [1], the raw private key is exported as a base64 encoded der. I don't understand what your concern is here. It appears that any cfx export file is not tied to a specific service to service import path, but can be imported into anything, or just used locally with self written tools. 1. https://fidoalliance.org/specs/cx/cxf-v1.0-ps-20250814.html#... | | |
| ▲ | lapcat 5 days ago | parent [-] | | This is merely the exchange format between credential providers, which is encrypted and gatekeeped by the credential providers. None of this is exported to users. |
| |
| ▲ | jmsgwd 5 days ago | parent | prev [-] | | 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 5 days ago | parent [-] | | 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. | | |
| ▲ | jmsgwd 5 days ago | parent [-] | | Once "secure credential exchange" becomes supported by commercial credential managers, what's to stop someone implementing an open source password manager that implements the standard and allows local export in plaintext? | | |
| ▲ | pseudalopex 5 days ago | parent [-] | | Passkeys relying parties can block providers. Tim Cappalli threatened the KeypassXC developers so.[1] The restrictions demanded now do not restrict user freedom significantly arguably. But the incentives and capabilities are clear. [1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss... | | |
| ▲ | jmsgwd 4 days ago | parent | next [-] | | OK but you'd still be able to use the open source "password manager" to export the keys - which solves the issue lapcat raised in this thread - even if relying parties blocked it for authentication, which would be a separate issue. Someone could develop a "passkey export tool" purely for the purpose of doing credential exchange then local export. Or are you saying the credential exchange process itself could block providers? | | |
| ▲ | pseudalopex 4 days ago | parent [-] | | You misunderstood lapcat I think. They wanted Passkeys stored locally exclusively. And they wanted to be able to use them. The issues are not separate. |
| |
| ▲ | timmyc123 5 days ago | parent | prev [-] | | Hi, Tim Cappalli here. Not sure how stating that my (an individual) opinions on a topic are evolving is interpreted as "threatened the KeypassXC developers". If you've been following along, you'll have seen that I am actually one of the biggest advocates of the open passkey ecosystem, and have been working really hard to make sure all credential managers have a level playing field. Always happy to chat directly if you have concerns! | | |
| ▲ | pseudalopex 5 days ago | parent [-] | | The threat you relayed was more serious than the threat you made. But it is a threat when a person with influence suggests they may support a punishment. The biggest advocates of an open ecosystem say attestation should be removed and no one should adopt Passkeys before. Is this your position now? The concerns were clear I thought. I would be happy to discuss this publicly. | | |
| ▲ | timmyc123 5 days ago | parent [-] | | Attestation is not used in the consumer passkey ecosystem. | | |
| ▲ | pseudalopex 5 days ago | parent [-] | | But it could be. Yes? | | |
| ▲ | timmyc123 5 days ago | parent [-] | | Not really. The attestation model defined for workforce (enterprise) credential managers/authenticators doesn't really work in practice for consumer credential managers. | | |
| ▲ | pseudalopex 4 days ago | parent [-] | | > doesn't really work in practice Avoid weasel words please. Is it possible in theory to use attestation or any other Passkeys feature ever to prevent a user to use any software they chose with any service they chose? | | |
| ▲ | jesseendahl 4 days ago | parent [-] | | In theory any code could be written at any time that does something good or bad. Sure. But in reality, the people who actually work on these standards within the FIDO alliance do not want a world where every website/service makes arbitrary decisions on which password managers are allowed. That would be a nightmare. | | |
| ▲ | deltoidmaximus 4 days ago | parent [-] | | Will be a nightmare. If they really didn't want this they wouldn't have put the tool to do it right in the spec. |
|
|
|
|
|
|
|
|
|
|
|
|
| |
| ▲ | mroche 5 days ago | parent | prev | next [-] | | 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 5 days ago | parent [-] | | Well, you can until they use the attestation feature to block your passkey manager implementation. |
| |
| ▲ | timmyc123 5 days ago | parent | prev | next [-] | | > 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. | | |
| ▲ | lapcat 5 days ago | parent | next [-] | | > Care to cite this statement? Yes, literally from you: "Passkeys should never be allowed to be exported in clear text." https://github.com/keepassxreboot/keepassxc/issues/10407 Also, "You absolutely should be preventing users from being able to copy a private key!" > You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain. But I want to use Apple Passwords. And I do use Apple Passwords for passwords. What you're saying, in contrast, is that in order to use passkeys, I would be forced to change how I currently store credentials, which is not in iCloud. "You can choose any method you like, except the one you currently like" is a pernicious interpretation of "choice". | | |
| ▲ | timmyc123 5 days ago | parent [-] | | You're quoting the first post of a long discussion, where the importance of protecting your data on disk was highlighted, and a proposal was made that at minimum, the default should be encrypting the backup with a user selected secret or key. > But I want to use Apple Passwords. You're choosing to use an app that doesn't meet your needs, when there are numerous apps out there that do meet your needs. I'm not sure how anyone is supposed to solve that for you. | | |
| ▲ | lapcat 5 days ago | parent [-] | | > You're quoting the first post of a long discussion "You absolutely should be preventing users from being able to copy a private key!" is the 8th post in the discussion. Do you stand by these words, or are you now repudiating them? > You're choosing to use an app that doesn't meet your needs I am using an app that meets my needs. I don't need passkeys. It's just other people telling me that I need passkeys. | | |
| ▲ | timmyc123 5 days ago | parent [-] | | Copy and paste in clear text? Yes, I don't think that's a good idea.
Download to disk in clear text? Yes, I don't think that's a good idea. Years and years of security incidents with consumer data show that this is a really bad idea. At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key. | | |
| ▲ | lapcat 5 days ago | parent | next [-] | | > At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key. It feels like this stated minimum is not your actual minimum. Consider for example a macOS user keychain. The keychain is encrypted on disk with a user-selected password. But once you unlock the keychain with the password, you can copy and paste passwords in clear text. The keychain is not a black hole where nothing ever escapes. And I have no objection to this setup; in fact it's my current setup. So when you say copy and paste of passkeys in clear text is not a good idea, there's nothing inherent to encrypting credentials with a user key that prevents such copy and paste. There would have to be some additional restriction. | |
| ▲ | pseudalopex 5 days ago | parent | prev [-] | | > At minimum, a credential manager distributed for wide use should encrypt exported/copied keys with a user selected secret or user generated key. What should happen if the developers refuse to enforce this? |
|
|
|
| |
| ▲ | Dagonfly 5 days ago | parent | prev [-] | | 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#iss... | | |
| ▲ | timmyc123 5 days ago | parent [-] | | 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 5 days ago | parent [-] | | Well it relates to this sentence: > You can use any credential manager you choose. Which I would be careful with. I can use any authenticator that the RP accepts. I could totally see a future where banks only allow certain authenticators (Apple/Google) and enforce this through AAGUID or even attStmt. Similar to the Google Play Protect situation. At that point, those banks/services would enforce vendor lock-in on me. The reality would be: I can use iOS or Android, but not a FOSS implementation. This restriction is not possible with old-school passwords. | | |
| ▲ | timmyc123 5 days ago | parent [-] | | If a website were to attempt to do this, you (or your credential manager) could simply change the AAGUID to match another credential manager. |
|
|
|
| |
| ▲ | happyopossum 5 days ago | parent | prev | next [-] | | > 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. | | | |
| ▲ | pastel8739 5 days ago | parent | prev | next [-] | | > 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 5 days ago | parent [-] | | > 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 5 days ago | parent [-] | | Oh, indeed, sorry. Yes I thought you were talking about the authentication process. |
|
| |
| ▲ | peanut-walrus 5 days ago | parent | prev [-] | | 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 5 days ago | parent | next [-] | | > 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 5 days ago | parent | next [-] | | So don't use software that forces lock-in (Safari)? Sounds like a you problem. | | |
| ▲ | lapcat 5 days ago | parent [-] | | > 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. | | |
| ▲ | peanut-walrus 5 days ago | parent [-] | | Again, this is a Safari problem, not a passkeys problem. You are literally complaining about missing features in Safari. |
|
| |
| ▲ | Ferret7446 2 days ago | parent | prev | next [-] | | Rather ironic to complain about lock in as an Apple user, there is no such problem on Linux. The problem isn't passkeys but Apple. | |
| ▲ | happyopossum 5 days ago | parent | prev [-] | | > Safari requires iCloud keychain for passkeys Repeating this doesn’t make it true. https://developer.apple.com/documentation/authenticationserv... All of the 3rd party credential managers I’ve used that support passkeys work with safari, and through the APIs that Apple offers the credential managers you can even pick your default CM and never think about iCloud again… | | |
| |
| ▲ | tdemin 5 days ago | parent | prev [-] | | [dead] |
|
|
