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!
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.
Not really. The attestation model defined for workforce (enterprise) credential managers/authenticators doesn't really work in practice for consumer credential managers.
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?
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.
This is one of the core use cases for why FIDO Cross-Device Authentication was created. To be able to use a passkey to sign in on a shared device, a device you don't control, or a device where you just need temporary access to something.
Logged into Passkeys.io on my phone, and created a passkey.
Then tried to log in to it on my Windows desktop, using the "With my phone" option. First time around it failed to connect to my phone. Future times it connected, but told me that the phone had no appropriate passkeys on it. At which point I gave up.
Edit:
I then tried on GitHub, and it worked perfectly! Okay, that's pretty awesome.
Last I heard, they were pushing hard for resident keys only, maybe that's changed. I don't like that there's still the option to restrict it to that in the same way having the option to force remote attestation makes me uneasy.
A passkey is a discoverable credential (aka resident key) in spec terminology. But the type of credential has no relationship to attestation (which is not used in the consumer passkey ecosystem).
Just to point out, protecting a key using the secure enclave and syncing it using end-to-end encryption aren’t necessarily mutually exclusive.
The security property you care about is that the plaintext key is only ever processed in use within the secure enclave (transiently, during authentication).
That doesn’t preclude syncing or backing up the encrypted key via a cloud service - if the device allows the application to do that.
Huh interesting, how does that work? I thought the way yubikeys operate the keys are generated on-device and are impossible to remove, and also come in limited number.
How do the decryption keys for the encrypted passkeys get shared between devices?
>Huh interesting, how does that work? I thought the way yubikeys operate the keys are generated on-device and are impossible to remove, and also come in limited number.
I wasn't referring to hardware keys (like YubiKeys), but rather on-device secure enclaves, TEEs, or TPMs.
Also I said "protecting a key using the secure enclave", which is perhaps a bit of a sleight of hand :-)
By that I mean a key that is wrapped (encrypted) using a parent key stored in the secure enclave. The key itself is not stored in the SE. But since it is wrapped using a parent key that is stored in the SE, that means it can only be decrypted in the SE. I believe this is how iCloud Keychain works, for example.
Digging into this further, it looks like I might have been wrong to imply that a credential manager app can instruct the SE itself to perform the proof of possession calculations needed for passkey authentication using a private key that is "protected" in this sense. When the app asks the SE to decrypt a passkey private key, it looks like the SE might return the passkey private key in plaintext to the app, and then the app itself performs the proof of possession calculation transiently outside the SE. I'm not sure about that, but I'd love to know.
> How do the decryption keys for the encrypted passkeys get shared between devices?
They get established as part of the device enrolment process. I suspect this simply adds another layer to the key hierarchy, so that your passkey private keys are encrypted under a sync key (parent) which is encrypted under a SE key (grandparent).
In that case, you could still claim that your passkeys are "protected by the SE" since they are encrypted at rest and in transit, and they cannot be decrypted anywhere except in the SEs of your enrolled devices.
> 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.
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".
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.
> 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.
> 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?
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.
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.
Your credential manager provides this sync and backup capability. There are dozens of credential managers available that work on all platforms. You don't have to use the default one on any given platform.
When was the last time you used a library computer, let alone logged onto a private service with it? This was a bad idea even 20 years ago. In today’s security climate, aw hell no.
Or my sisters laptop. & Fairly recently actually, to print something. Most accounts I don’t care that much about & two factor should be enough to save me I hope.
Hi! I'm the commenter on that post that keeps being brought up!
I don't think requiring an encrypted backup (with a key or secret that YOU control) by default is "preventing users from being able to export their own private keys".
Hi! I have no issue with having the backup being encrypted by default, except the discussion returns again and again to disallowing any cleartext export, even when specifically requested by the end user.
And on a separate note, I fundamentally disagree for political reasons with the idea that the websites should be able to block specific passkey providers.
You say "requiring by default". That makes no sense in this context (or most) - you can either require something (which is not "by default") or you do not (at which point you can encourage something as strongly as you like, but it's still not required).
The github issue is quite clear about "requiring", not "by default", which is a restriction on what someone does with their own data. Particularly since AFAICT there is still no spec for data exchange over flat files. CXP is a probably-reasonable more-safe option to encourage, but it really shouldn't be the only option.
(arguably CXF only defines non-encrypted files, since it doesn't even recommend encryption options or provide a way to communicate what was used, except to say that it "MUST" encrypt or coordinate over CXP)
Right now, when I go to the security section of my Amazon account in Chrome, it (unasked) prompts me to add a passkey, and the popup on my Mac says, verbatim:
> Add a passkey? "amazon.com" supports passkeys, a stronger alternative to passwords that cannot be leaked or stolen. A passkey for "xxxxx@xxxxx.com" will be saved in "Passwords". Touch ID to Save Passkey Cancel
I don't have the slightest idea what "Passwords" is as the destination. My iCloud keychain? My Google account? My 1Password?
OK, on the one hand TIL -- thank you! That's a super-meaningful piece of information.
On the other hand, you can understand why that is not remotely clear from the message. It's a generic term in quotes. If it said it would be saved "in the Passwords application (and synced to iCloud)", then I'd actually understand it.
So Apple is either being intentionally obtuse or incompetently confusing here, and I don't know which is worse. And it's UX crap like this which is why I still won't use passkeys, because I don't know where anything is going.
Exactly passkeys are confusing to the laymen (and not Laymen) because it’s is an orchestration across multiple services and devices.
If I’m using a passkey to login to my Gmail via chrome browser but used my phone what just happened - did it save in chrome? My Google account? My iPhone?
Not exactly. For example, the default credential manager on Android is Google Password Manager, which works on Windows, macOS, iOS, and Ubuntu. There are also dozens of other third party choices.
This is one of the core use cases for why FIDO Cross-Device Authentication was created. To be able to use a passkey to sign in on a shared device, a device you don't control, or a device where you just need temporary access to something.
On the one hand, that seems really important and I'm happy to know it exists.
On the other hand, I thought I had fully researched how passkeys work and literally never came across it.
So it kind of just continues to support my concern that passkeys are just too complicated to understand. If I'm at another device I need to log into, I would have just assumed I couldn't.
There needs to be a simple mental model for users. I'm not saying passkeys can't underlie that, but I think the UX still just hasn't been fully figured out yet.
I used the technical name for the capability, but you've likely run into it before.
If there is no passkey on the local device, a QR code will appear which you can scan with your phone or tablet, and use the passkey for the account from that device. It just kind of happens, typically without the user having to do anything special.
I will say though, corporate devices can be a bit of a wildcard as they are usually configured and locked down for a specific purpose. But the cross-device flow is generally not blocked by organizations.
I don't use passkeys, so I haven't run into it. It seems like that screen would be gated behind entering an e-mail address or username that is already registered with a passkey on another device.
What I'm saying is, I thought I had the right mental model of how passkeys work, after researching them, and that mental model told me you wouldn't be able to log in on a different device without going through a whole procedure to set up a new passkey, which you wouldn't want to do for something temporary.
The mental complexity is just too much for me to trust that if I adopt them, they'll work when I need them. The fact that I got this thing wrong means there's probably other things I'm still getting wrong.
I understand passwords and password managers and even 2FA. I feel like I can plan how to use them right so it all works and I don't need to worry about not being able to access my accounts. I just don't have that confidence with passkeys.
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!