Passkeys should not be resident keys when deployed

[Firstyear]

Select Topic Area

General

Body

In the blog https://github.blog/2023-03-09-raising-the-bar-for-software-security-github-2fa-begins-march-13/ the authors discuss that github is experimenting with passkeys internally.

Unfortunately due to community split about what "passkeys" should mean there are multiple definitions. Sadly the prevailing definition is that "passkeys must be resident keys". (resident=required).

However, since yubikeys and other security keys will always be accepted in areas a "passkey" will this causes significant issues. First, most keys lack storage space for resident keys - ranging from 8 to 32 key slots - which will rapidly fill up when more sites push for residency.

But second and far worse is that many keys that are CTAP2.0 (which is the vast majority of keys in use) do not support the ability to alter or delete resident keys once created. Since resident keys also include small amounts of PII such as names this can cause significant issues for members of the transgender community or women who are changing their names. The only way to remove these keys is to reset the entire device, wiping all it's resident keys and resetting it's internal primary key breaking all resident and non-resident keys ever registered.

Since resident keys have the potential to significantly harm individuals in the community, github should prioritise that it's passkey implementation does not force key residency. The options in webauthn must be set to "resident=discouraged" as preferred and required will both trigger this issue.

Thanks,

EDIT: Worth pointing out that as a relying party (auth provider) there is no way for you to detect if a key is ctap2.0 or otherwise during registration meaning there is no way to selectively ask for residence or not. Also important to note that even if you set resident=discouraged you will still have access to conditional UI because devices like Apple's Passkeys will always create resident keys even under discouraged and will have access to conditional UI. Apple Passkeys also do support PII updating and management so these are not a risk to individuals. So you will still gain the benefits of residency on keys that support it opportunistically, but without causing harm to users - best of both worlds!

[nsatragno]

The only way to remove these keys is to reset the entire device, wiping all it's resident keys and resetting it's internal primary key breaking all resident and non-resident keys ever registered.

This isn't completely accurate. The relying party can register a new credential for the same user id, and it should overwrite the previous one. An RP like GitHub can even instruct users to do that after they change their username or display name.

[Firstyear]

Will that work on ctap2.0? It's still a pretty rough user experience.

[nsatragno]

Yes, it works on CTAP 2.0 as well. Agreed the UX isn't great.

[MasterKale]

I think GitHub is between a rock and a hard place here. While it's true that iOS will always create a discoverable credential regardless of the options passed to it, Android requires Relying Parties to "opt in" to passkey creation by setting either residentKey: "preferred" or residentKey: "required" during registration. This includes during what was historically the "just Security Keys" registration flow, because you can't know ahead of time if an Android phone will scan the cross-device registration QR code that the browser shows.

I offer a counter-point to @Firstyear's position: Relying Parties must always at least prefer resident key creation during WebAuthn registration. The idea here is that GitHub has more to gain from encouraging as many authenticators as possible to create a passkey that will likely get synchronized and thus survive device loss. Getting a user to register a credential that will get backed up would allow for many more users to retain access to their GitHub accounts if they trade in their phones, for example, or have to replace it because it "fell into the ocean". This position, admittedly, assumes that the majority of users opting into WebAuthn-based account protection here will be using their on-hand mobile device as opposed to users who choose to embrace the security key life.

To be clear, I don't like that RP's have been put in this unenviable position through inadequate authenticator selection options in WebAuthn. Given the current state of passkey providers, though, I think it's best for Relying Parties to optimize for passkey registration across Apple, Google, and eventually Microsoft-influenced platform authenticators for the sake of maintaining account access after device loss.

[Firstyear]

Account recovery being bound to key residence is the problem of a vendor - there is nothing that says the key-wrapped-key master can't also be synced in a cloud account.

Trading "username autocomplete" at the expense of making almost all currently available keys un-usable due to space/storage limits, and the potential harms that can come from misnaming a person is not a fair or reasonable trade.

[MasterKale]

Account recovery being bound to key residence is the problem of a vendor - there is nothing that says the key-wrapped-key master can't also be synced in a cloud account.

But RP's have to design user experiences around capabilities that exist now or we have been told are coming. To date none of the usual authenticator vendors have proposed such a scheme of syncing anything other than discoverable credential key materials.

And the trade-off in my mind is not "username autocomplete", it's "full account access out after device loss". And updating a discoverable credential's name after a name change event is as simple as re-registering with the same RP ID and user ID. Isn't discoverable credential storage even on CTAP2.0 authenticators still a map with keys comprised of RP ID + user ID? Why wouldn't it be that simple?

[Firstyear]

RP's have to implement this workflow and indicate that this (rather un-intuitive pattern) is how you update a username.

Also how do I fit 100's of resident keys in devices that only store 8 keys? 20 keys?

If we force residency, rather than rely on residency as opportunistic, then every fido device sold today is effectively not fit for purspose, and we are risking surprising users when will fill their devices with credentials they can't delete (sure they can update - but they can never be deleted on ctap2).

If key residency for account recovery is so important, then google/ms can force residence under discouraged. Let's not destroy fido keys that already are in circulation, and that we have been recommending people to buy for years. We will alienate our users.

[Firstyear]

But RP's have to design user experiences around capabilities that exist now or we have been told are coming

Right, like designing around fido keys that already exist and are in circulation.

Why are we ignoring these so furiously for things that we are "told is coming" .

[DollahBaraka]

How to get trade key

[Samonitari]

members of the transgender community or women who are changing their names

To be completely fair, don't exclude men. They can change their names too, where I live even as a result of marriage (which I presume was the reason you highlighted women): they can adopt or partially adopt their spouses family name.
Also, not just women can earn a doctorate, medical degree, etc. (fun fact: a neighbour country even adds/allows a name prefix for engineers) 👅

[savely-krasovsky]

This is very strange proposal. Discoverable credentials is the future. If your key is dated -- update to newer ones. Newer Yubikeys come with up to 100 passkeys storage. Token2 tokens come with up to 300 passkeys. This is more than enough to use residential keys for literally everything and enjoy usernameless flow.

[Firstyear]

The new google titan key comes with 200 slots, and you can't manage/delete/change them because it's only CTAP2.0. So you know, this whole RK future is going great 👍

I also still have working yubikeys that are fw version 5.4 so they only have 25 slots. So don't make assumptions that everyone will just "buy new keys" when they already have working ones.

But regardless, this ship has sailed, resident keys are the thing being pushed, and now we have to "suck it up". That's how it be.

[savely-krasovsky]

@Firstyear your original post feels like everyone already had two old FIDO2 tokens which they casually use everyday since ages. C'mon, USB-tokens are extremely niche product for big enterprise companies and security-minded geeks. I am into the second category and I really enjoy to authenticate using only token. Not even memorizing username or email (which I personally generate for each service randomly).

Also in my opinion 200 passkeys is more than enough to just use RK on every site possible and still have a plenty of room without even need to worry about space. For example right now I used only around 30 slots, though I add passkeys always when I see it.

[LB--]

FWIW, GitHub did a big advertising push for time-limited GitHub-branded YubiKeys years ago when they were relatively new things, so a lot of people just have those early models and don't feel a need to buy the same thing again to get functionality they don't understand. To call security keys niche on GitHub is to ignore how much GitHub has and still does push its ordinary users to get one.

[savely-krasovsky]

For old keys owners there is old U2F which is still supported. Yes, password will be required, but from security standpoint it's as secure as FIDO2 non-residential credential.

[johndavidjohn22]

This is a really important and well-explained point. Supporting non-resident keys by default seems like a practical and more inclusive approach—especially given the hardware limitations and personal data implications you mentioned. Thanks for highlighting this nuance.