Web Authentication (WebAuthn) is our best technical response to
phishing, which is why we’ve championed it as a technology. All major
browsers either support it already, or have their support in-progress,
yet adoption by websites has been slow. The deprecated Javascript API
that WebAuthn replaces, the FIDO U2F API [0], is mostly confined to
Chromium-based browsers.
# tl;dr #
To make security keys work with Google Accounts in the near future, I
propose enabling our FIDO U2F API for google.com domains, controlled
by a whitelist preference. Waiting on Google Accounts to fully support
Web Authentication will probably take too long, since it’s Android
deployments which are holding them up.
# Background #
More than a year ago, I proposed here an interim solution to permit
Google Accounts to use existing FIDO U2F API credentials in Firefox
[1] which was implemented in Bug 1436078. We agreed then to implement
a hard-coded permission for Google Accounts when utilizing FIDO U2F
API credential support, whether that was via Web Authentication’s
backward compatibility extension, or via Firefox’s FIDO U2F API
support hidden behind the “security.webauth.u2f” preference.
We’ve recently learned that Google Accounts has slipped their schedule
for using Web Authentication to register new credentials. This delay
is attributed to security key support on Android being, for most
devices, non-upgradable. WebAuthn is backwards-compatible with
credentials produced by the FIDO U2F API. However, WebAuthn-produced
credentials cannot be used with the FIDO U2F API. Because of that,
credentials created using WebAuthn will never be usable on the
majority of FIDO U2F-only Android devices currently in circulation.
Due to this issue, there has been an unclear timeline communicated to
me for when Google Accounts will support registering security keys
using Web Authentication.
# Proposal #
It appears that if we want full security key support for Google
Accounts in Firefox in the near term, we need to graduate our FIDO U2F
API support from “experimental and behind a pref” to either “enabled
by default” or “enabled for specific domains by default.” I am
proposing the latter.
## Thorny issues in enabling our FIDO U2F API implementation ##
This is not as simple a decision as it might appear. Certainly we want
to encourage adoption of Web Authentication rather than the FIDO U2F
API. There have already been sad cases of well-known web properties
implementing the deprecated standard after we shipped WebAuthn [2].
There’s also the matter that we haven’t built-out the whole of the
FIDO U2F API.
Firefox’s implementation of the FIDO U2F API is deliberately incomplete:
First, we only implemented the optional Javascript version of the API,
not the required MessagePort implementation [3]. This is mostly
semantics, because everyone actually uses the JS API via a
Google-supplied polyfill called u2f-api.js. But the specification is
the specification.
Second, we do not perform the “Trusted Facet List” portions of the
“Determining if a Caller's FacetID is Authorized for an AppID”
algorithm [4] from the specification (we stop at step 3). It seems:
under-specified [5]; of dubious security/privacy advantage [6]; and
it’s rarely necessary [7].
I don’t intend to invest the engineering time to fix the above issues
(neither coding nor spec-wrangling). The anti-phishing future is Web
Authentication, and we should only care about getting Firefox users to
that future.
# Enabling the whole FIDO U2F API for Google Accounts #
Conventional wisdom says that the largest installed base of security
keys in-use remains with Google Accounts, whether via GSuite or public
accounts. It appears that the only way we get Firefox users of Google
Accounts fully able to use security keys is to enable FIDO U2F API
support so that said users can enroll via FIDO U2F API, and then
authenticate via … well, either. We will have to trust that Google
will roll out authentication-via-WebAuthn quickly for the sake of the
standard moving forward.
This also would solve a longstanding issue where users of Tor Browser
can’t enroll in Google Advanced Protection, despite the clear
advantages.
## What this looks like in code ##
First, I would change the existing security.webauth.u2f pref from
being enforced via WebIDL annotation to in-code checks.
Next, I propose to add a new pref:
pref("security.webauth.u2f_enabled_domains", “google.com“);
This would be a list of domain names that would be matched against the
caller, specifically: If one of the listed domains is a registrable
domain suffix of or is equal to [8] caller’s origin’s effective
domain, we’d enable the FIDO U2F API for that domain.
Finally, I would remove the “aOp == U2FOperation::Sign” check from
EvaluateAppID in WebAuthnUtil.cpp, permitting the Google override to
work for Register as well as Sign.
# Concluding thoughts #
As I’ve tried to establish, I’ve had reasons to resist shipping the
FIDO U2F API in Firefox, and I believe those reasons to be valid.
However, a multi-year delay for the largest security key-enabled web
property is, I think, unreasonable to push upon our users. We should
do what’s necessary to enable full security key support on Google
Accounts as quickly as is practical.
I’ve proposed here making the FIDO U2F API whitelist a pref. I can’t
say whether I would welcome adding more domains to it by default; I
think we’re going to have to take them on a case-by-case basis.
[0] I consistently say “FIDO U2F API” in order to disambiguate versus
the wire-protocol used to communicate with “FIDO U2F”-compatible
security keys, and the associated data formats. The overloading of
“FIDO U2F” or “U2F” is an easy source of confusion, and I want to be
clear here.
[1]
https://groups.google.com/d/msg/mozilla.dev.platform/Uiu3fwnA2xw/201ynAiPAQAJ
[2]
https://aws.amazon.com/blogs/security/use-yubikey-security-key-sign-into-aws-management-console/
[3]
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#low-level-messageport-api
[4]
https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-appid-and-facets-v1.2-ps-20170411.html#determining-if-a-caller-s-facetid-is-authorized-for-an-appid
[5] Under-specified meaning questions like: Where’s the CORS
preflight? What happens if that fails? Why isn’t the MIME type
registered with IANA? Etc, etc.
[6] The point of the FacetID algorithm for the web is to be a way to
completely bypass the single-origin security policy; WebAuthn adopted
a stricter origin “relaxing” mechanism [8].
[7] Google Accounts needed it in a very small way. Coding around it
was the point of last year’s post, and it was a ~15-line patch.
Facebook also needs it in a much more complex way, but I’ve heard they
don’t expect an issue re-enrolling users to move to WebAuthn.
[8]
https://html.spec.whatwg.org/multipage/origin.html#is-a-registrable-domain-suffix-of-or-is-equal-to
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
