Description
Event Timeline
Some quick notes for when this is started:
- U2F only works in Google Chrome at the moment, as it requires speaking to the actual device.
- Yubico provides libraries and a standalone server for U2F. It'd probably be best to have options for both.
- PHP library: https://github.com/Yubico/php-u2flib-server and https://developers.yubico.com/U2F/Libraries/Using_a_library.html
- Standalone server: https://developers.yubico.com/u2fval/ and https://developers.yubico.com/U2F/Standalone_servers/U2FVAL_REST_API.html and https://github.com/Yubico/u2fval-client-php
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.
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
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.”
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).
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)
A press release from W3 and FIDO; W3C and FIDO Alliance Finalize Web Standard for Secure, Passwordless Logins.
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.