Passkeys Credential Exchange
Filipe Espósito (Hacker News, MacRumors, Dan Moren):
As just announced by the FIDO Alliance, the new specifications aim to promote user choice by offering a way to import and export passkeys. The draft of the new specifications establishes the Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) formats for transferring not only passkeys, but other types of credentials will also be supported.
[…]
1Password, which worked with the FIDO Alliance on the new specifications, has already committed to supporting the new passkey import and export formats as soon as they become available. Other companies such as Dashlane, Bitwarden, NordPass, and Google also worked on the draft of the new specifications.
Although nothing has been said about Apple, the company is also part of the FIDO Alliance and was one of the first to introduce support for passkeys in 2022 with iOS 16.
I don’t love this framing because, to me, “export” means that it generates a standalone file that I can do with what I please. I can edit it. Or back it up and import it later—possibly into a different app. As far as I can tell, this is not that. It’s more of a way to transfer passkeys between password managers. It’s specifically designed to “export” an encrypted blob that can only be read by the password manager that requested the export. There’s no use even storing the exported file because, unless you have a way to back up the receiving private key, you won’t even be able to import it again. Maybe a third-party developer will make an app that requests/receives an export and lets you access your own data.
Export and import should have been extremely simple. Instead, they took years to come up with some convoluted system where the only possibility is to transfer from one vendor lock-in to another vendor lock-in.
The FIDO Alliance would probably say that not allowing true exporting makes it more secure, but I think that’s only true in a kind of security-through-obscurity way. If you make an encrypted happy path for transferring credentials, people will use it because it’s easier. Credential exchange does open the way for people to get at the decrypted data—it just makes it a pain and requires trusting an additional helper app. (Or are they going to somehow prevent non-big-players from participating?) If someone has direct access to my Mac and unlocked password manager, it’s game over, anyway. So I fail to see what this is really protecting against. Do they think people will export CSV files and leave them on unencrypted storage?
“It is critical that users can choose the credential management platform they prefer, and switch credential providers securely and without burden,” the FIDO Alliance wrote in its press release.
It’s about platforms, not giving you control of your data.
This is a big improvement, but I’m still very wary of any authentication system whose secret I can’t easily write down on a piece of paper.
Yes that may seem insecure, but I would also consider having a system that pretty much only major vendors can support to also be insecure in other ways. Loss of access is just as bad as being hacked as an authentication failure point.
I really want to like Passkeys given they’re technically much better, but their flaw is they require you to trust Big Tech (and do so in a far more important way than with passwords). Unfortunately Big Tech has used up pretty much all its remaining trust budget 🤷♂️
I particularly resent how they’re treating their proprietary, heavily networked implementations in always-connected devices as superior to a mostly-airgapped FIDO2 device. Those USB key like devices don’t have great UX, but I’d rather see some iteration on that idea than allowing Big Tech to silently sync (i.e. delete, copy, insert, etc.) those secrets in my phone.
Micah R Ledbetter (via Hacker News):
Passkeys are a technically interesting idea with many upsides, but I am concerned about the power they take away from users.
[…]
The passkey spec is designed intentionally such that:
- Sites that use passkeys, like your bank, can tell what app you keep your passkeys in
- Site that use passkeys can choose to support some apps and not others
This is not a hypothetical concern – it’s being discussed today with regard to the open source KeePassXC app.
[…]
The second ticket linked above makes it clear that sites are prepared to block passkey apps not just for their default settings, but for allowing certain actions to happen at all. In that ticket, the concern is that passkeys can be exported without being encrypted.
There are FIDO Alliance folks posting Github issues requesting to remove features such as plaintext exporting of credentials, with the explicit threat that the Alliance might block such “open” passkey providers in the future. A local database is not enough, it needs to be locked in a secure element or protected with some TPM-like scheme.
The spec allows for hardware attestation as well, to ensure passkeys are being provided from blessed computing environments. Hopefully implementers continue to ignore this anti-feature, because it’s entirely stupid to lock out users who want to control their own security; at the same time, letting anyone with an Android phone restore passkeys from the cloud with one of their device PINs.
I would also be concerned about whether you can recover when a provider becomes unusable or hostile, and there is no cooperative migration path.
That might be the company going bankrupt, a physical or digital disaster, geopolitical firewalls, or simply a Kafka-esque bureaucracy where your entire account has been deleted without appeal because the company decided it was easier than figuring out the truth behind some moderation issue.
David Heinemeier Hansson (Lobsters):
We had originally planned to go all-in on passkeys for ONCE/Campfire, and we built the early authentication system entirely around that. It was not a simple setup! Handling passkeys properly is surprisingly complicated on the backend, but we got it done. Unfortunately, the user experience kinda sucked, so we ended up ripping it all out again.
The problem with passkeys is that they’re essentially a halfway house to a password manager, but tied to a specific platform in ways that aren’t obvious to a user at all, and liable to easily leave them unable to access of their accounts. Much the same way that two-factor authentication can do, but worse, since you’re not even aware of it.
With this blog post, I want to share with you the learnings on my way when working on a passkey-first auth solution and passkey intelligence with Corbado. All the hard truths, the unknown unknowns (factors that were not anticipated prior to my experience, essentially things we did not know we did not know), and the misconceptions should be uncovered, so that you know what to consider when implementing your own passkey-based authentication.
[…]
Implementing passkeys in a real-life project is 100x harder than you might initially think (trust us – we’ve gone through it).
Jeff Johnson (Mastodon, Hacker News):
I don’t want to place my credentials database under someone else’s control and because I don’t trust the availability and reliability of cloud sync. I prefer to manage credentials myself. Thus, I was surprised to find two passkeys in the “Passkeys Information.csv” file. I don’t recall ever creating a passkey.
[…]
What I didn’t realize until now is that enabling iCloud Keychain also automatically generated
apple.compasskeys. I must have missed it at the time or forgot, but Apple automatically assigned passkeys to users of iOS 17, iPadOS 17, and macOS 14 Sonoma. Since passkeys require iCloud Keychain, it makes sense that this happened the exact same time that iCloud Keychain was (forcibly) enabled on my iPad. However, I seem to have lost the passkeys when I manually disabled iCloud Keychain, because the new Passwords app in iPadOS 18 shows zero passkeys. I have no idea how to revoke the lost credentials on Apple’s systems.My question is, why does Apple have all of this personal, private information, stored in plain text?
Previously:
- Apple Passwords App in Sequoia and iOS 18
- The Dark Age of Authentication
- Apple Updates Silently Enable iCloud Keychain
- Family Passwords and Passkey Providers
- Passkeys: A Loss of User Control?
- Passkeys
- Requesting Your Personal Data From Apple
Update (2024-10-17): Dimitri Bouniol:
For what its worth, exporting passkeys is non-trivial, because authenticators are sometimes expected to count how many times they’ve signed a challenge, specifically so the server can ensure it hasn’t been copied and used on the side by a non-trusted 3rd party 😔
9 Comments RSS · Twitter · Mastodon
> Do they think people will export CSV files and leave them on unencrypted storage?
Yes. This can/does/will happen. Give people a menu option of "export to CSV" and 1000% it will happen. They will save it to their desktop. They will email it to themselves in plaintext. They will not delete it when they're done. Everything they can possibly do "wrong" they will do.
I’m also missing my Apple passkey in Passwords app as I use 1Password. I have keychain sync enabled bu5 I don’t use the Passwords app. It just has Wi-Fi networks and a few “sign in with Apple” accounts. I’d like to add an Apple passkey to 1Password but I don’t see any way to do that. Like 2FA being proprietary with no option to use TOTP for an Apple account Apple seemingly only allows a passkey for their Apple / iCloud in their ecosystem. I don't even see a way to generate a new Apple passkey in Passwords if the auto generated one is missing or never existed.
Do they think people will export CSV files and leave them on unencrypted storage?
I've seen how messy and cluttered people's desktops and downloads-folders are — especially with old crud that the owner should have deleted months or years ago. Emphatically yes.
I share everyone else's concerns about vendors setting the stage for absolutely awful and ironclad vendor lock-in, but "user too clueless to put exported .csv in a place that is not backed up by anything and also the user doesn't delete the .csv when the export/import process is done" is very much a thing that likely happens a lot, at least among users who move from one password manager to another (especially once password managers go more mainstream in 5–10 years).
@Skullvalanche @Nathan I think most users are going to use the built-in password manager or stick with what they have. Anyway, if the littered CSV file is the main concern, they could have simply designed a password-protected export format (or used an encrypted ZIP archive). There was no need to lock users out of their own data, other than that that seems to be their philosophical goal.
I'm not proud of it, but I managed to recover from a loss of credentials by using the unencrypted CSV export from 1Password that was sitting in my Downloads folder for months.
I'd consider myself well above average on the technical ability and security consciousness, but still left it sitting there for months getting backed up to Time Machine (thankfully encrypted, but still)
I already can store my passkeys where I want in the open KeePass file format. The password manager Strongbox uses such files to store passwords and also passkeys. I don’t known, if other keepass capable tools can use them, but the Strongbox makers say so.
Quoth Michael Tsai:
There was no need to lock users out of their own data, other than that that seems to be their philosophical goal.
As much as I want to agree…I can't.
If you lock people out of their own passwords, they can't be phished:
I've got users who, by literally no fault of their own, are being social engineered into reading back their SMS OTP codes to fake tech support.
Passkeys are the first positive step in auth I've seen in a decade that the average user will pickup and use, it helps them login and helps them not try to set a weak password they shared with multiple sites, and they can't read it back to a scammer who is fake tech support.
"If you lock people out of their own passwords, they can't be phished"
This is actually false. The irony is that as soon as the Passkey Credential Exchange is implemented, passkeys become phishable. All an attacker has to do is trick a victim into approving a transfer request from the victim's passkey provider to a passkey provider controlled by the attacker. Then the victim's passkeys are transferred to the attacker, who can use them to access the victim's accounts.
Read the working drafts of the Credential Exchange Protocol, and check out the "Security Considerations" section. It's a farce! They haven't even considered security yet.
@Nathan @Jeff That’s why I say it’s security-through-obscurity. They are trying to protect users by making it more difficult to hurt themselves, but it’s not actually a leak-proof system.
