-
Notifications
You must be signed in to change notification settings - Fork 154
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
Remove U2F #439
base: master
Are you sure you want to change the base?
Remove U2F #439
Conversation
@kasparsd note that this relates to #423 (comment) wherein the next step after removing U2F is the determining the best path forward from here (happy to hear your input there). |
So this handles the code change, my only uncertainty at this point is whether we should do something to handle the data / ux. That being, if someone had U2F enabled, but no other providers, would its sudden absence disable 2fa on their account entirely, and is that a case in which we should force enable an alternative, such as emailed codes so there is still some second factor? |
Yeah, this is a really important point! Otherwise this looks good! |
@jeffpaul Do you have any thoughts on what the workflow should be if a user only has u2f enabled but no others? |
Hi, U2F will be removed in v.0.8 but it will be still possible to use physical keys with webauthn? #427 Also - when we can expect v.0.8 release? |
@georgestephanis if a user only has U2F enabled and the plugin is updated to whatever version this removal will be part of (e.g. 0.8.0), then we could possibly go with one of the following:
What are your thoughts on this? |
If we end up switching libraries in #427, then I think we could seamlessly migrate the existing U2F keys to the WebAuthn provider. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@georgestephanis Can you update this pull request with master
because PHPUnit tests are falling in this pull request?
Discussing with @georgestephanis at WC US, we think it would be a good idea to "fail closed" here. That is, if someone has only the U2F 2FA method available, when we remove support for it, we don't want the user to have 2FA bypassed. Instead, we think we can enable the Otherwise, we should return a |
@georgestephanis @TimothyBJacobs as discussed at WCUS Contributor Day, and besides the merge conflicts here, are there any additional updates or tweak to approach to getting this on towards merge? |
Yeah so I think this still needs adjusting for the changes to "fail close" instead of fail open. Since this will probably require a bit more work. If we do want to get a U2F fix in sooner rather than later, it probably makes sense to go with #571 now. |
I agree that fail-close to Email makes the most sense here, and that's only an edge-case for when Backup Codes are not enabled. Due to how long U2F has been broken, I don't think we actually need to matter too much about this though, the affected users have been locked out of their sites for a while now unless they're running severely outdated browsers.. |
As discussed with @jeffpaul with its deprecation we should remove the provider.