Page MenuHomePhabricator

WebAuthn (U2F) integration for Extension:OATHAuth
Closed, ResolvedPublic

Description

Research and, if possible integrate WebAuthn (FIDO2, U2F) authentication as a method for two-factor authentication.

Note that FIDO U2F is a legacy protocol. Together WebAuthn and CTAP provide a complete replacement for U2F.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Parent5446 raised the priority of this task from to Needs Triage.May 25 2015, 9:57 PM
Parent5446 added a subscriber: Parent5446.

Some quick notes for when this is started:

Just pinging to say I saw this and I'm thinking about it.

I started playing with this a while back using a *heavily* modified fork of OATHAuth. It's nowhere near the point that I'd be comfortable sharing it though.

I'm also interested, and intend to take a stab at implementing it sometime over the next few weeks. @Krenair @dpatrick let me know if you've started work on something worth basing my attempt off of.

There was another attempt today to break Wikipedia accounts of several prominent users. This would help us greatly.

I would like to support this request as well, it is very helpful

There was another attempt today to break Wikipedia accounts of several prominent users. This would help us greatly.

I do note, just getting wider deployment of OATHAuth would be an easier (and quicker) win. I just filed T166622 as I can't find a current task...

I'm not 100% sure whether U2F would work better for some people, or just cause confusion. Or if just providing another option is a good idea generally (which I think it probably is)

We know of a few usability and social issues filed in MediaWiki-extensions-OATHAuth that we want to get fixed at some point

Izno triaged this task as Low priority.Aug 14 2017, 2:47 PM

Why was a security-relevant-task marked as “low”?

Not all security related tickets are vulnerabilities. In particular, this
is a new feature request.

@Krenair: If it would be a vulnerabilitiy, the priority would be “high” if I’m not mistaken. I asked why this was lowered from “normal” to “low”, while it asks for an improvment in a security relevant area. In my eyes such a request should have a higher priority than an cat-image-generator.

@DaBPunkt our priorities reflect reality and not aspiration:
See also: https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels

If we have a ticket about a cat-image-generator that no one is actually working on, you are welcome to set that ticket to lowest :)

@TheDJ: I see. Now I begin to understand why the WMF never handles the important stuff: Nobody cares about the important stuff, so it is marked as “low”, and because it is marked as “low”, nobody cares about it.

“Though this be madness, yet there is method in 't.”

@DaBPunkt: The Etiquette asks you to have "meta-level discussions on priorities in general" somewhere else. Likely the same for discussing "the WMF".
Thanks in advance for staying on-topic.

@TheDJ: I see. Now I begin to understand why the WMF never handles the important stuff: Nobody cares about the important stuff, so it is marked as “low”, and because it is marked as “low”, nobody cares about it.

“Though this be madness, yet there is method in 't.”

Patches are welcome.

U2F was implemented in Firefox 57, we're now at 61. It still has to be set manually. Enter about:config?filter=security.webauth.u2f in the address bar, hit return, and set it to true.

Yes it works, I'm using a U2F-key in Firefox on an Ubuntu box right now to log in to LinkedIn, Twitter, Dropbox, etc. I'm also using it on Gmail in Chromium. Works like a charm.

Given this now works in FF (albeit with some config) I think this has some value and I'm going to have another go.

There seems to be a lot of confusion around this. This is my (possibly mis-) understanding, based on some googling:

  • Originally, there was the FIDO U2F standard which describes a Javascript interface between the website and the browser, various protocols (USB, NFC, Bluetooth etc) for the browser talking to the second-factor device, and a protocol for the device talking to the web server with the mediation of the browser.
  • The website-to-browser and device-to-server part of the protocol is now superseded by WebAuthn, which is a W3C standard (CR) since two months ago. It also generalizes login flows - instead of a second factor, the device can now be single-factor (passwordless login) or one of multiple factors (e.g. hardware key + biometric identification device).
  • the browser-to-device part is now being superseded by FIDO2 CTAP (which also supports single-factor and multi-factor). This part doesn't really concerns us.
  • The FIDO U2F API is supported by Chrome and Opera (desktop only), and supported behind a feature flag (security.webauth.u2f) by Firefox. The standard is superseded, so nothing else will support it. Here's a test page.
  • WebAuthn is supported by Chrome, Opera, Firefox and Edge (which un-feature-flagged it two months ago). It's also supported on mobile (caniuse claims no Chrome support but according to Chrome platform status it's supported since 70, and I can verify it works). Here's a test page.
  • CTAP is backwards-compatible (it defines two protocols, CTAP1 for two-factor which is basically just U2F and CTAP2 for single-factor/multi-factor, which is not U2F-compatible), so all old devices (Yubikey etc) work with WebAuthn for second-factor but not the other flows. The Javascript part is not backwards-compatible. I'm not sure about the device-to-server protocol but I think it's also backwards compatible.

So there is not much point in integrating U2F proper (everything that supports it supports WebAuthn but not the other way around), we should do WebAuthn instead.

There are some PHP libraries, none from a trusted party though. As I said, I'm not sure whether U2F (for which there's a fairly authoritative PHP implementation from Yubikey) can be used instead.

Wikipedia says that "Existing FIDO U2F Security Keys are largely compatible with the WebAuthn standard, though WebAuthn added the ability to reference a unique per-account "user handle" identifier, which older hardware tokens are unable to store." Not sure how interesting that is for us.

Also apparently there are some concerns around some of the crypto protocols, which might be good to keep in mind (this concerns the device-to-server part).

There seems to be a lot of confusion around this. This is my (possibly mis-) understanding, based on some googling:

  • Originally, there was the FIDO U2F standard which describes a Javascript interface between the website and the browser, various protocols (USB, NFC, Bluetooth etc) for the browser talking to the second-factor device, and a protocol for the device talking to the web server with the mediation of the browser.
  • The website-to-browser and device-to-server part of the protocol is now superseded by WebAuthn, which is a W3C standard (CR) since two months ago. It also generalizes login flows - instead of a second factor, the device can now be single-factor (passwordless login) or one of multiple factors (e.g. hardware key + biometric identification device).
  • the browser-to-device part is now being superseded by FIDO2 CTAP (which also supports single-factor and multi-factor). This part doesn't really concerns us.
  • The FIDO U2F API is supported by Chrome and Opera (desktop only), and supported behind a feature flag (security.webauth.u2f) by Firefox. The standard is superseded, so nothing else will support it. Here's a test page.
  • WebAuthn is supported by Chrome, Opera, Firefox and Edge (which un-feature-flagged it two months ago). It's also supported on mobile (caniuse claims no Chrome support but according to Chrome platform status it's supported since 70, and I can verify it works). Here's a test page.
  • CTAP is backwards-compatible (it defines two protocols, CTAP1 for two-factor which is basically just U2F and CTAP2 for single-factor/multi-factor, which is not U2F-compatible), so all old devices (Yubikey etc) work with WebAuthn for second-factor but not the other flows. The Javascript part is not backwards-compatible. I'm not sure about the device-to-server protocol but I think it's also backwards compatible.

So there is not much point in integrating U2F proper (everything that supports it supports WebAuthn but not the other way around), we should do WebAuthn instead.

Adding that Microsoft since very recently started supporting authentication to Microsoft accounts via U2F security keys (USB/NFC) and Windows Hello (biometrics/camera) in Edge.

I guess we should research Windows Hello support as additional authentication factor(s). Owning such a camera, I can say it works surprisingly good and secure, secrets bind only to the device it's set up on (TPM), and secure enough for to not recognize a picture of myself pointed to the camera.

Obviously, this requires support for several factors first (T172079: Allow OATHAuth users with 2FA already enabled to add / switch devices without disabling)

jeblad renamed this task from U2F integration for Extension:OATHAuth to WebAuthn (U2F) integration for Extension:OATHAuth.Mar 10 2019, 12:38 PM
jeblad updated the task description. (Show Details)

Apparently someone else may be working on this

Note from webkit:

  • [WebAuthn] Enable WebAuthn by default for MobileSafari and SafariViewService

FYI I tested the latest WTP, and this implementation currently does not work with it (why i'm not sure yet). It just reports a Timeout (well, after I added a console.log() because it seems we hide all errors reported by that API).

Tested again at home. It does work with my yubikey, but Safari and WTP don't present any meaningful UI during the .create() and .get() stages, which makes it a tad confusing.