Turn on WebAuthn in wp-admin

[StevenDufresne]

For the MVP, let's turn on WebAuthn in the upstream plugin and verify that it works. If it does, I think we can launch with support for privileged users and iterate, adding support for all users.

• Decide which approach to take
• Port MadWizard to upstream PR
  • Fork upstream WebAuthn provider #134
  • Port WebAuthn registration to MadWizard library #146
  • Port login and test flows to use MadWizard library
  • Cleanup and improvements
  • Holistic code review now that the finished piece can all be seen together, rather than smaller PRs where much of the code is temporary
• Enable WebAuthn plugin in wp-admin #153
• WebAuthN: Disable EdDSA/Ed25519 for key registrations #165
• WebAuthn changes required for production #169
• Update WebAuthn: Link to wp-admin until custom UI is built. #141 to show if enabled/disabled state programmatically.
• Get security review and iterate
• Enable the link to wp-admin from WebAuthn: Link to wp-admin until custom UI is built. #141

[iandunn]

We'll need to decide which back-end provider to use. These are the options that I see:

• The upstream PR: Ideally we'd just use upstream directly instead of maintaining something else, so this might help that. It's not clear if it will be merged, though, or if it'd be a good fit for w.org.
• Volodymyr's plugin. This looks very good and I'm using it on a personal site. I haven't tested it extensively, though.
• We could also write our own provider, and try to make it something that could eventually be turned into a PR for upstream. This would probably be the largest amount of work, though. We'd also have to build a UI for it, either for wp-admin or integrating with our custom UI.

Regardless of the approach, we'll want to get a security review. I added a checklist to the issue description so we don't forget.

@pkevan @StevenDufresne @dd32

[StevenDufresne]

I'm inclined to go with the first option with the necessary updates as it benefits the community and brings the two factor plugin more up to date in regards to feature support making it more likely to be used and therefore more likely to be maintained.

[iandunn]

Integrating #134 and #146 is turning out to be more time consuming that I hoped, so I'm going to look into running WebAuthn Provider for Two Factor without any customizations -- or minimal customizations -- instead.

If that works well, we could look into if it'd make sense to propose merging it upstream instead of being an add-on.

One issue might be eventually needing to migrate keys from the plugin to upstream, but given the time constraints we'll probably just need to deal with that if it happens.