My team at work recently purchased Yubikeys in order to investigate ways in
which we could use them internally across the company. I quite like the concept
of hardware-based two-factor authentication keys, so I was excited to also set up
Yubikey-based authentication across the other products that I use, including my
Google account. I switched on U2F in the about:config page in Firefox and went
to the Google security page, only to be met with a popup saying “Your current
browser doesn’t support adding Security Keys. Try again in Chrome browser.”:
I was puzzled by this: U2F authentication shipped with Firefox 57 some time ago. Initially, I suspected that this might be Google either forgetting to update their pages, or Google aggressively pushing Chrome as they have done in the past. A quick search on Twitter pulled up several people pointing the finger at Google, but with no real information about how the situation had come about. Further digging, however, showed that the situation is a bit more complex than Google-bad, Mozilla-good, and has to do with an aspect of the U2F spec called ‘Facets’. I haven’t been able to find a concise summary of all of the information I had to trawl through, so I decided to write one myself.
If you’re not familiar with the way in which U2F works, the FIDO Alliance website is a good place to start. In short, once you register with a website, assymetric cryptography is used to ensure that you’re really talking to the same website for all your future login attempts using the U2F key that you registered with. The standard is fairly easy to understand, but also has to account for the fact that large organisations might want to authenticate users across a large number of domains. This is where Facets come in.
Facets attempt to address the fact that a large number of different applications running on different domains might want to use the same authentication infrastructure. In these cases, the organisation can provide a ‘Trusted Facet List’, which is basically a set of hostnames that you want a particular U2F key to work across. You can see Google’s Trusted Facet List here. If the origin of your authentication request is in the Trusted Facet List, then (providing you authenticate successfully, of course!) the U2F operation is allowed to proceed.
This superficially seems straightforward, but there appears to be some confusion regarding the implementation. To begin with, Firefox doesn’t implement the Trusted Facet List. The very short reason for this is that the maintainer who works on the area is primarily concerned with implementing WebAuthn, and doesn’t want to spend time on U2F when (ideally) it is going to be superseded by WebAuthn in the near future.
This has given rise to the idea that Firefox isn’t able to support U2F auth
on Google properties because it hasn’t implemented the Trusted Facet List alone.
I don’t think this is the case, for a number of reasons. I have read the FacetID
spec a few times now, and as I understand it, the restriction on hostnames is
such that All Web Origins listed MUST have host names under the scope of the
same least-specific private label in the DNS, where least-specific private
label is defined as the portion of the host portion of the AppID URL that
matches a public suffix plus one additional label to the left.
Note that this doesn’t match the case with Google, where the AppID URL has a
host of www.gstatic.com but the list of valid FacetIDs includes hosts like
accounts.google.com. There are three further reasons why I believe that Firefox
wouldn’t be able to validate this cross-origin authentication request according
to the spec:
- This Google Groups note which claims that Google themselves have hardcoded the gstatic/google.com relationship in Chrome (I don’t understand the code well enough to verify).
- The last two posts in this
Google Groups thread
which suggest that the only reason why
gstatic.comserves the Trusted Facet List is because Google implemented the protocol prior to the formal spec. - This Bugzilla post
by one of the authors of the FacetID spec suggesting that the initial
definition of valid FacetIDs was too strict (although this doesn’t
touch on the
gstaticissue at all).
So even if Mozilla had implemented the Trusted Facet List, I don’t think that they would have been able to support Google without using custom code - much like Google already does for their own browser!
With that puzzle (somewhat) deciphered, where does that leave people using Google accounts with Firefox? Firefox has added some hardcoded values that will allow you to authenticate using U2F keys on Google properties, but not do any new key registrations. This is because WebAuthn is coming, and Mozilla - from what I can tell - intends to implement that specification completely. U2F has been deemed a legacy protocol and this hardcoding (to be reviewed in 2023) is only to support existing users. So when Google says “You current browser doesn’t support adding Security Keys”, that’s true in a very specific sense - Firefox doesn’t support adding keys alone, and that’s only for Google accounts. It’s probably a message that could be better worded on the Google site, because I think it gives a false impression, but in either case, with WebAuthn on the way soon, hopefully this entire blog post will shortly be a redundant relic of a more insecure time.