Concerns about passkeys

Updates

2024-07-22: In my original post, I misunderstood when migration will be part of the standard. I read this comment to mean that it will be available two or more years from the time the comment was posted, but apparently the correct reading was that it has been in progress for two or more years. Thanks to Matthew Miller for pointing this out, and mea culpa for the bad information.

Original post

Passkeys are a technically interesting idea with many upsides, but I am concerned about the power they take away from users.

Passkeys cannot be exported

Passkeys are held in whatever app originally created them. They cannot be backed up, migrated to a competing application, or otherwise exported. You can’t take your passkeys from Apple Passwords and put them in 1Password. Instead, you have to log into each website one by one and change your passkey app.

Releasing them like this is asking for trouble. They should allow migration between passkey providers before they’re offered to the average user at all.

(Migration between passkey apps is planned, but not yet available.)

But they’re being enabled by default

I really can’t believe that Apple is migrating existing accounts to passkeys by default in new versions of iOS and macOS without the ability to migrate away from Apple as passkey provider.

This means that, by default, logging into an account which used to use only a password that can be entered on any device will change the account to require a passkey that’s only available on devices Apple supports for all future logins.

This should not have shipped.

Discriminating against passkey apps

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.

KeePassXC and noncompliance

KeePassXC supports passkeys. Earlier this year, a senior architect for identity standards at Okta opened a pair of issues in the KeePassXC bug tracker:

In these issues, he describes KeePassXC behavior that is out of spec, but KeePassXC developers respond that they believe it is in their users’ best interests.

In the text of the first issue is a threat: “This implementation is not spec compliant and has the potential to be blocked by relying parties.” A “relying party” is a website that uses passkeys, so this means that if an app doesn’t implement passkeys the way websites want, sites will just block the passkey app. What the user wants can’t override what the website wants.

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. Merely warning the user about unencrypted passkeys is apparently not sufficient (see follow up comments one and two).

And the threat is made more explicit:

I’ve already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).

keepassxreboot/keepassxc#10407

Sympathies for discrimination

I understand why site want to be able to block apps like this. From the point of view of (say) a bank, users with insecure credentials are not just a problem for the user, they are a liability to the bank itself. Of course banks want as much control as possible over liabilities. To be maximally fair to banks and other sites, the less they pay to manage their liabilities, the cheaper their services can be to regular people (their customers).

On the other hand, it’s bad for society if only vetted and authorized entities can build passkey apps, and it’s bad for users if they can’t choose to use a particular passkey app.

Corruptable levers

Finally, a more general concern. Passwords are inherently decentralized. Each user creates their own passwords and stores them or remembers them or forgets them according to their own choices. Websites can check passwords at scale, or require that passwords have certain attributes like a specific length or characters from certain classes, but that’s it. And this environment of user choice is both terrible (it gets us password123) and excellent (it gets us password managers).

With passkeys, however, there is now a standards body and a way to discriminate between passkey apps. Sites can try to pressure the standards body into forcing users to do things like reauthenticate whenever the site asks (the issue behind that first KeePassXC ticket), and can block apps that won’t implement the standard. It also gives identity provider companies, including Okta mentioned above as well as the big ones like Microsoft/Google/Apple etc more leverage over users than they already have.

I don’t think this concern should sink the whole idea of passkeys, but I do think that the passkey standards body should create cultural norms that counteract it, like erring on the side of user agency. I am concerned that what I see in the KeePassXC tickets indicates that this isn’t happening enough.

􀀂􀀟􀀍􀀆 􀀂􀀛􀀌􀀋 Concerns about passkeys