-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
WebAuthn: prefer discoverable credentials with legacy fallback #57140
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.
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
WebAuthn: prefer discoverable credentials with legacy fallback #57140
Conversation
- require resident keys/UV for new FIDO2 registrations, but retry without if unsupported - allow username-less login by probing discoverable credentials first, then fall back to the old flow - keep legacy (non-discoverable) registration/login paths working for older authenticators
|
Thank you for your contribution! |
|
OK, will do.
Thx
Hubertus
clipped mail content
|
|
Non-discoverable passkeys aren't "legacy", and they are useful when using a hardware tokens with limited number of key slots. Registering a discoverable key should be an explicit action from the user:
|
|
OK, I will add a checkbox, no prob.
The login method supports both methods anyhow.
good idea!
|
|
With the setting, this is an appreciated feature 👍 (talking as a user). BTW, we still need to fix this issue to get passkey only login: #44342 |
|
Yes, choosing discoverable or non-discoverable credential is a must. Also, UV must be mandatory for discoverable credentials. We don't want totally passwordless+usernameless logins without even a PIN (or other UV), this would be a disaster. Or there could be an option to disable UV with big red 'I understand the risks' warning (ideally, this should be controlled by admins depending on organization policies). |
this is as follows: if ($requireDiscoverable) { |
|
Shouldn't it be |
good and valid point in my opinion. Having a user option for RESIDENT_KEY_REQUIREMENT_REQUIRED, RESIDENT_KEY_REQUIREMENT_DISCOURAGED more likely forms the real opposite. |
|
This work is greatly appreciated! Thank you! I will test when I have the time! In the meantime, am I understanding this correctly?:
|
|
In my opinion, the correct thing to do would be to treat all WebAuthn credentials as a form of :
At least, this is how it's implemented right now: existing non-discoverable credentials are form of passwordless login (and the corresponding header in WebAuthn credentials are generally regarded as secure and thus do not require 2FA. 2FA is usually required for passwords only, in order to compensate for some of their weaknesses (passwords can be stolen/leaked, reused/sprayed, bruteforced etc, unlike WebAuthn credentials). UV is a whole different dimension. It's goal is to protect WebAuthn credential on user's side from unauthorized use. Imagine if someone finds a Yubikey in the street with
Note another use case for WebAuthn: on many websites, it's used as a better alternative to TOTP codes. In this case, UV is indeed optional, or even often discouraged, because the user already has to provide a password. By the way, this is exactly how it's implemented with Two-Factor WebAuthn app. A good UX example would be GitHub itself: https://github.com/settings/security We have:
Their docs are actually very good and worth reading: https://docs.github.com/en/authentication/authenticating-with-a-passkey/about-passkeys So, I'd envision the UI in Passwordless AuthenticationSet up your account for passwordless authentication following the FIDO2 standard. These credentials can be stored on hardware keys, or managed by your OS, or in some password managers. The following WebAuthn credentials are configured for your account:
Register new WebAuthn credential:
As for my proposal for an option to disable UV for passwordless logins (not usernameless+passwordless!), it could be hidden inside that |
|
Not sure how the interest is at all here. I would like to make it really simple... |
|
I do recommend to consider #57154 for further discussions regarding stable32. |
Updated by #57154
Summary
TODO
Checklist
3. to review, feature component)stable32)