Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The reason for that RK is mandatory #16

Open
keikoit opened this issue Sep 29, 2020 · 18 comments
Open

The reason for that RK is mandatory #16

keikoit opened this issue Sep 29, 2020 · 18 comments

Comments

@keikoit
Copy link

keikoit commented Sep 29, 2020

On "5 User-Verifying Roaming Authenticators (UVRAs)", it seems RK is mandatory, I would like to know the reason why we cannot user NRK. In our understanding, it is working on NRK with username.
Does this mean CTAP2.1 require RK?
Or just focus on RK because discussion about NRK has already explained previous section?
@sbweeden
Copy link
Contributor

The NRK scenario is 2FA. The UVRA scenario is for performing bootstrap login on a new device without using a password. This requires RK.

@maxhata
Copy link

maxhata commented Sep 29, 2020

Using UVRA, you can bootstrap login using NRK by asking users to input account name. If this flow is not intended in this section, we should clearly state why this is not intended in this section. Otherwise, it confuses readers a lot.

@keikoit
Copy link
Author

keikoit commented Oct 5, 2020

In section 5.1, there is the following explanation;
When the user clicks on “Register your security key”, you call navigator.credentials.create(), taking care to specify “cross-platform” for the attachment type, requiring user verification, and requiring a resident (aka discoverable) key[15].

Is "requiring a resident key" mean UVRA is only supported by RK? Or it is just example and we can use NRK too?

@eldanb
Copy link

eldanb commented Oct 15, 2020

In section 5.1, there is the following explanation;
When the user clicks on “Register your security key”, you call navigator.credentials.create(), taking care to specify “cross-platform” for the attachment type, requiring user verification, and requiring a resident (aka discoverable) key[15].

Is "requiring a resident key" mean UVRA is only supported by RK? Or it is just example and we can use NRK too?

+1 on this question

@christiaanbrand
Copy link

Technically this use case can also work with non-discoverable credentials, but in that case the user would still have to enter some identifier. We're trying to simplify the use cases in this doc a bit, so decided to omit this interim user journey where users would replace their password, but not the identifier.

@keikoit
Copy link
Author

keikoit commented Oct 30, 2020

@christiaanbrand -san
Thank you for your comments.
I understood the background. How about add the note such as the following one to the first half of the chapter to avoid user confusion? Readers who are already using non-discoverable credentials may also read this doc, and it would be easy to understand to read if the prerequisites were clarified.

i.e.
"Technically this use case can also work with non-discoverable credentials, but we focus to describe discoverable credentials cases as a sample"

@micolous
Copy link

micolous commented Apr 14, 2023 •
edited
Loading

Unless you have some very specific use cases (eg: using enterprise-specific extensions, and where you control the authenticators provided to users), it's a bad idea for an RP to use anything other than rk = discouraged:

  • Unlike non-discoverable credentials, discoverable credentials (RKs) consume storage space.
  • Hardware authenticators have very limited storage space.
    • For example, the Yubikey 5 has a maximum of 25 slots. My password manager has over 100 credentials stored in it, so I'd need to carry more than 4 authenticators if all those sites decided to use rk = preferred or required.
    • Discoverable credentials are also variable size, so it's difficult to reason about that storage generally.
  • Hardware authenticators (including those made by companies contributing to the WebAuthn and FIDO specifications) are marketed to users as having "no limit to the number of accounts" or "secure login on a practically unlimited number of services" - which is only true when using non-discoverable credentials.
  • There is a mechanism (remainingDiscoverableCredentials) for an authenticator to report how many storage slots remain, but this is not a mandatory feature (and then, that's only potentially available for FIDO 2.1).
    • Without this feature, a user registering with an RP who uses rk = preferred will always have the browser try to create a discoverable credential, which can potentially fail!
    • Even when this feature is available, at present, no browser or platform supplies any UI for this.
  • Credential storage management is only mandatory in FIDO 2.1:
    • FIDO 2.0-only keys have no mechanism to manage credential storage - other that factory-resetting the key and losing all credentials.
    • FIDO 2.1-PRE keys have an optional mechanism to manage credential storage.
    • At present, no browser or platform supplies any UI for this either.
  • Even with rk = preferred, browsers will always try to use discoverable credentials if an authenticator reports supporting it (unless it explicitly reports remainingDiscoverableCredentials = 01), with no way for the user to opt-out.

The only benefit a typical (ie: non-enterprise) RP gets is being able to skip the username field, which only works if rk = required, and could have been done with browser auto-fill. Using rk = preferred means you could end up with non-discoverable credential, which needs a fall-back flow (asking for a username).

Using rk = discouraged doesn't mean you'll never get a discoverable credential. For example, Apple devices using Touch/Face ID will always create discoverable credentials backed up in the user's iCloud account. It would be possible for other vendors to implement the same thing within their ecosystem, while also allowing use of hardware security keys and not filling up their storage space.

An RP can still require PIN/UV authentication (for strong single-factor authentication) without requiring resident keys. However, many hardware keys (like Yubikey) have no way to disable discoverable credentials without also disabling FIDO2 support, which means they are back to being a U2F device with no PIN/UV support. 🙃

In short:

  • rk = preferred has zero benefit over rk = discouraged, but draw-backs for both the RP (implementation complexity) and users (bricking keys).
  • rk = required has limited benefit for a typical (ie: non-enterprise) RP, but draw-backs for users (blocking or bricking keys).
  • There is no way for a user to opt-out of rk = preferred - browsers will always try to use it if a key supports it.
  • The most reliable way to prevent RPs creating discoverable credentials will also disable PIN/UV authentication.

The UX problems would be largely fixable with some pretty minor changes to the WebAuthn specification and browsers. For example, browsers could require an enterprise policy configuration to allow certain sites to create credentials with rk = required, and not create resident keys on portable authenticators when rk = preferred.

Footnotes

  1. Even then, the spec suggests that authenticators should provide maximally-conservative estimates, and it could be possible that creating a credential would succeed... so browsers might try anyway. ↩

@christiaanbrand
Copy link

christiaanbrand commented Apr 14, 2023 via email

@micolous
Copy link

Hmm. I don’t think I agree. In your example users will keep typing usernames forever. I want them to plug in their key, choose their account, perform their local-auth to the key, and the sign-in. No typing.

@christiaanbrand Chrome has had form and username auto-fill for longer than it's supported U2F. The users who have synchronised / backed up credentials in Chrome (though only on Android today) also have synchronised auto-fill.

Outside of browser password managers, an RP who wants to auto-fill the username field can do this in a cookie, in the same way that they can use a cookie to "Remember Password" today... which is also how accounts.google.com works.

In short, you can have "no typing" today without resident keys.

Because of this Google will most definitely be making “RK=preferred” keys.

As I mentioned before, with rk = preferred, you can still end up with non-discoverable credentials, so you still need to prompt for a username and handle non-discoverable credentials.

The only way that you get "no usernames" is with rk = required.

It’s sad that in some cases the space on these keys are severely limited, but I hope this problem is actively being addressed by vendors.

The storage is only "severely limited" because goal posts have been moved on them. There is no guidance in the FIDO 2.0, FIDO 2.1 or WebAuthn specifications about how much storage is "ideal". As such, any change should be approached cautiously.

Incidentally, Google Titan Keys don't resident keys or user verification - they don't even support FIDO 2! OpenSK does, but targets a different SoC, and the OpenSK stable branch only supports FIDO 2.0, which has no storage management, but seems to have 200 slots (which is a lot more generous than most keys).

There are also compliance requirements (eg: FedRAMP) which mandate the use of certified security keys, so it's not like everyone can migrate to using their smart phone (which has much more storage for resident keys): they'll need to migrate everyone to a set of new hardware keys with more storage, and absorb all the support and logistics costs.

Not every organisation hands out security keys like candy - so is the group pushing rk everywhere planning to compensate those who now need to replace all their keys? 😉

@Firstyear
Copy link

The only way that you get "no usernames" is with rk = required.

Just to point out, rk=preferred is also identical in behaviour to rk=required in safari and chrome, meaning there is no "only make rk's if storage is unlimited". See w3c/webauthn#1822

It’s sad that in some cases the space on these keys are severely limited, but I hope this problem is actively being addressed by vendors.

@christiaanbrand So does that mean that every single existing fido2 credential that people own should be thrown out and is now obsolete junk? Seems like a big waste to me.

@christiaanbrand
Copy link

christiaanbrand commented Apr 17, 2023 via email

@Firstyear
Copy link

Firstyear commented Apr 17, 2023 •
edited
Loading

So you mean, you want typingless flows as an option but not as a requirement?

Because today that's not possible. rk=required/preferred force rks. rk discouraged only opportunistically creates them on iOS. You either require typingless - or you don't. And the only way to make it an option is rk=discouraged.

(edit) also to point out, as an RP you can not know ahead of a registration if a key has unlimited rk storage or not, so you also can't filter out devices that would have their space consumed ahead of time.

So the reality is we will have to throw out our keys and get new ones if rk=required/preferred is pushed as the default - simply put, we will fill up the device storage rapidly. It may not be what you want to occur, but it is what will occur. The worse alternative it people will choose not to use webauthn. There are already cases I am aware of with Microsoft's Azure AD where admins that manage multiple tennants have been forced to stop using yubikeys as they have filled the storage on them, and have reverted back to password + totp only.

@micolous
Copy link

micolous commented Apr 17, 2023 •
edited
Loading

My goal is to have completely “typingless” flows; not only on reauthentication (when cookies exist), but on initial bootstrapping too. That’s where resident credentials come in very handy.

How is this not achievable today?

When you create a new account with an RP, you're providing some sort of personal identifier in that flow (either manually, or through form auto-fill), which can be stored through the browser sync (just like a synchronised resident key) or through a site setting cookies.

The place where you'd miss out is mobile apps: but it's a good idea to shell out to the system's web browser for authentication anyway, because the user can use their password manager (for "legacy" credentials), and it makes your implementation significantly simpler (as you just need an intent handler to finish the flow).

No one needs to “throw out” their current credentials/keys: they just won’t support full typingless flows.

I disagree with this assertion, because this doesn't match what Chrome on Android is doing today on consumer devices (ie: something without an @google.com or other Google Workspace account on it).

You can see this yourself by visiting https://webauthn.io and registering a new credential:

  • with rk = preferred (default) or rk = required, you are only prompted to "create a (Google) passkey".

    You can choose which Google account it is synchronised to, but you have no option to use device-bound or portable authenticators (assuming you're OK with consuming limited storage space).

  • with rk = discouraged, you can choose device-bound or portable authenticators, but then you lose the option to use a Google passkey.

While I acknowledge this outcome was probably unintended, and Chrome took steps to avoid breaking existing credentials, this issue combined with strongly advocating RPs use resident keys have the effect of making hardware security keys unusable for any new registrations.

By comparison, Safari on iOS and macOS present the option to use an iCloud-synchronised credential first (regardless of rk setting), but has an escape hatch ("Other Options") to use caBLE or portable authenticators. Apple is trying its best to make sure hardware security keys remain usable on their platforms.

@micolous
Copy link

PS: here's a screenshot of Chrome on Android with rk = preferred:

Screenshot_20230417-182331

Plugging in a USB-C security key, or using an NFC security key doesn't work, and that drop-down at the bottom only lets me pick a different Google account.

It's only when using rk = discouraged (which has a totally different UI) that you can use hardware security keys.

@huaracheguarache
Copy link

Are we still on course to make security keys useless? Or has something changed for the better?

@Firstyear
Copy link

Are we still on course to make security keys useless? Or has something changed for the better?

There have been no changes. Rollouts such as on github have already forced resident keys leading to feedback such as https://github.com/orgs/community/discussions/67791#discussioncomment-7075862 where people can't use them because they have filled the RK's on their keys.

There have thankfully been at least two major vendors (and plenty of smaller users) who are following the warnings we have put in this channel but it's the exception not the norm.

I think at this point the major vendors are so focused on the blue sky dream, that they aren't willing to look at the issues real humans are having with both resident keys but also caBLE/hybrid and cloud based passkey managers. I have serious concerns at this point about the future of passwordless without some significant changes.

@huaracheguarache
Copy link

Really sad to see.

@christiaanbrand while you said earlier that security keys will not use discoverable credentials, that's not the case. Two of the slots on my YubiKeys are used up by my two Google accounts (personal and work). The decisions you make have consequences. I imagine users of current gen security keys will be forced to retire them and replace them with likely much more expensive keys with greater secure storage capacity.

@micolous
Copy link

micolous commented Oct 26, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@micolous @Firstyear @christiaanbrand @maxhata @sbweeden @keikoit @eldanb @huaracheguarache