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 😔
Update (2024-10-18): Lawrence Abrams:
Amazon has seen massive adoption of passkeys since the company quietly rolled them out a year ago, announcing today that over 175 million customers use the security feature.
I would not call it quiet since when users log in it prompts them to add a passkey. If you don’t store cookies it will ask you every time.
This is a worrying decree of platform lock-in. I expect a lot of issues when people lose access to their devices or try to login from a new computer.
Currently, this is not an issue because Amazon allows both password and passkey access to the same account (thus negating some of the benefits of passkeys). But the goal is for passkeys to replace passwords, and some sites already prevent you from using both. So backup and transfer of passkeys are very important.
Apple’s Ricky Mondello has been entertaining my questions about this. My conclusion is that the current situation (pre-CXF and CXP) is not good. You have very little control over your passkeys and can easily get into trouble if something goes wrong. There is always the option of using recovery, e.g. sending a special link to your e-mail, to generate a new passkey. Some people do this as a matter of course whenever they need to log in because they don’t remember their passwords. This horrifies me, as I think of passwords more as irreplaceable secrets to be carefully guarded. Recovery via e-mail (or postal mail) does not easily scale to large numbers of logins, and I don’t think it’s very secure, as people often leave their mail open on an unlocked device. And, as passkeys replace passwords, it may be difficult to access your e-mail without a passkey, creating a circular problem.
When Credential Exchange becomes available, I think it will help a lot, though I still have some concerns.
The Passwords app seems unlikely to support backups directly, so you would need to periodically export manually to maintain control of your data. Will this be limited?
As I suggested in the initial post, it will be possible to write an app that lets users truly export their data, not just transfer it. I was worried that, because sites can block certain authenticators, such an app might only be useful as a utility and could not be used as an actual password manager. It seemed that this was being used to pressure KeePassXC into not allowing exports. However, Mondello says that the identification is “extremely intentionally, an optional unattested hint string.” In other words, like a Web browser’s “User-Agent,” the password manager could identify itself however it wants.
I still don’t like that sites get to see which password manager I’m using. This is a privacy violation, as I doubt the big players are going to let me use a custom user agent. But if this is at least possible (in future versions or with indie password managers) it would prevent users from being locked out due to sites not liking a particular authenticator or big players going to war with each other.
At this point, I would say that I’m cautiously optimistic. However, the whole passkeys system is so complex that I’m sure there are important questions that I don’t even know to ask and failure modes I haven’t considered.
The credential exchange protocol introduces phishing to passkeys.
What stops an attacker from tricking a victim into approving a transfer of passkeys to a credential provider under the control of the attacker? I’ve read the working drafts, and they’re appalling terse on the subject of security considerations.
I don’t have strong feelings about passkeys, but I am vaguely unsettled by them. There’s no way to use passkeys without using a proper password manager, like Apple Passwords with iCloud Keychain, or 1Password. But if you’re using a proper password manager, your passwords should all be unique and random, and you should have convenient access to 2FA codes. So what’s the point of passkeys if they can only be used by people who are already using a good password manager? Perhaps the thinking is that too many users just can’t be budged from the risky habit of using passwords they have memorized, and passkeys are a way to break that habit because they can’t be memorized.
The main benefits vs. a password manager seem to be that users can be phished and convinced to bypass the safe auto-fill and that incompetent sites store unsalted passwords, which can then be leaked.
A friend texted me with another argument for passkeys: it’s somewhat common for websites to break password autofill. Maybe it’s deliberate, in the name of fighting bots? But whether deliberate or not, with passkeys, they have to work with your browser’s connected password manager. So maybe passkeys are a net win for convenience, even for technically-knowledgeable users who are unlikely to fall for phishing scams.
They are also more convenient than 2FA.
I think a lot of the passkey discourse(™) comes about because we’re a cohort of highly technical early adopters who already have password managers set up with sync, autofill, and two-factor auth. For those users, passkeys might lack some features (although I think the gaps are being filled rapidly there), but they aren’t really the people for whom passkeys are a big improvement.
From the other side of this correct consideration, the point is to explain to the non tech users that from now they will need to use a password/passkey manager. This introduces complexity for them.
A bit of feedback: the main problem to me is not the security factor (passkeys are more secure than passwords, period) but the apparent lack of control and ownership of my credentials.
[…]
Why is an Apple platform, macOS, seemingly intentionally hiding my own credential to my Apple account, at least in the Passwords app?
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.
