1409573 - u2f: Google should use standard U2F auth flows

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Harlan Lieberman-Berg]

Hello Mozilla,

Though progress is continuing on U2F support in Firefox nightly, Google's offerings for U2F are currently incompatible.  Even when using Firefox Nightly with the U2F flags set and setting the UA string to match a Chrome browser, attempting to register a U2F token through Firefox causes an error.

There doesn't appear to be any useful debugging output in the browser console.  This seems unrelated to 1340738, as Google's U2F test appspot[1] works just fine, even without browser string modification.

It would be good to have Google supporting this functionality when the U2F features in Firefox make it to stable.

Comment 1

[Karl Dubost💡 :karlcow]

It seems related. But gmail fails for users when prefs security.webauth.u2f and/or security.webauth.webauthn set to true 

See https://webcompat.com/issues/12810

Comment 2

[Harlan Lieberman-Berg]

I believe this is actually https://webcompat.com/issues/9975

Comment 3

[Mike Taylor [:miketaylr]]

jkt, do you know who is working on u2f who might know more about this situation? thanks.

Comment 4

[Jonathan Kingston [:jkt] he/him]

I'm sorry Mike I totally missed this!
:jcj is likely to answer this question, I think he has been in contact with Google regarding this however not certain.

Comment 5

[J.C. Jones [:jcj] (he/him)]

Regarding the comment 1's https://webcompat.com/issues/12810:

Arnar in the Google security team just debugged that issue in Bug 1441814 comment 10:
> I believe this is happening because enabling security.webauth.u2f adds a new
> global "u2f" on window, which is short enough to be used by JS compilers.
> 
> We (Google) have added "u2f" to the list of names that the compiler is not
> allowed to generate, and expect this to be fixed once that propagates to
> frontend builds.

As to comment 0, about Google not supporting Firefox-with-U2F: The Google Accounts team needed Bug 1436078 before they could move forward. Since that's now in Firefox 60, they're working on it on their side. I don't know a timeline.

Comment 6

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 7

[lolipopplus]

As how I tried just now, I can use soft token U2F for Google account without UA faking.
This ticket shall be close hence.

Comment 8

[ggramaiz]

lolipopplus (In reply to lolipopplus from comment #7)
> As how I tried just now, I can use soft token U2F for Google account without
> UA faking.
> This ticket shall be close hence.

I concur with your comment, as I can reproduce on Firefox 62.0a1 (build: 2018-05-24) on Windows.
I'll try to reproduce on linux soon.

Comment 9

[Dmitri Smirnov]

Under linux, FF 62.0a1 (2018-05-30) (64-bit) still gives me the following message on Google:

Use your Security Key in Chrome
Security Keys don't work with this browser. Try again in Chrome.

While working fine on other sites supporting U2F (Bitwarden, example test sites).

Comment 10

[Harlan Lieberman-Berg]

Agreed; it is still not working on Linux [62.0a1 (2018-05-29) (64-bit)].  Switching the UA to Chrome errors as it always has, and switching the UA to FF Nightly on Windows gives the same UA filtering error as when reporting the true UA.

Comment 11

[J.C. Jones [:jcj] (he/him)]

I am pinging the Google Accounts team about comment 9 and comment 10.

Comment 12

[J.C. Jones [:jcj] (he/him)]

Hey folks, I heard back from Google. This should be working on Linux. 

Let me make sure: Using the U2F support, Firefox is supported for _sign in_, but not new security key _registration_. This is because we made a deliberate choice in Bug 1436078 to limit the security risk/exposure of the hard-coded values to already-registered keys (Bug 1436078 comment 3). If you add a security key with Chrome, now or in the past, it should work in Firefox for sign in on any platform.

I'm sure that isn't what you're hoping to hear, but I just want to make sure that there isn't an _unexpected bug_ here, so please do let me know if this is broken on sign in or on registration.

And of course, WebAuthn is coming soon to Google Accounts, and supersedes all of this -- Chrome 67 with WebAuthn support launched yesterday. :)

Comment 13

[Harlan Lieberman-Berg]

Aha!  I was testing the registration workflow.

The login workflow appears to work correctly on Linux for me.  Good to resolve as complete on my end.

Comment 14

[Dmitri Smirnov]

I can confirm the login flow works with u2f token on FF62a1 (doesn't for 60 and 61b) for both GMail and Google Suit (sometimes there is a slowdown in feature rollout to GSuite accounts, so I just wanted to be sure).

Comment 15

[Mike Taylor [:miketaylr]]

It sounds like we can close this then (unless I'm mistaken...). Thanks all!

Comment 16

[Lindhe94]

Do I need to flip any switches in about:config for this to work?

Comment 17

[Lindhe94]

Yes: security.webauth.u2f.

Comment 18

[greg-mozillabugs]

I tried the Google login flow using FF 62.0b12 (64-bit) downloaded from Mozilla on Linux Ubuntu 18.04.1 LTS. The flow works on this same machine in Chrome.

I made sure to enable the following switches:

security.webauth.u2f;true.
security.webauth.webauthn_enable_usbtoken;true

The last page of login flow where I need to touch the token never changes from the animation. The javascript console shows a somewhat useless message:
time out callback

The source link next to the message takes me to this line of javascript:
_.g.connect=function(a){var b=T3a[this.g];if(b){var c=this,d=b+"-ping",e=function(){c.j.removeEventListener("message",f,!1)},f=function(d){d.data==b+"-pong"&&(c.c=!1,e(),window.clearTimeout(h),window.setTimeout(function(){c.j.addEventListener("message",c.uP.bind(c),!1)},0),c.a=!0,a(0))};c.j.addEventListener("message",f,!1);var h=window.setTimeout(function(){window.console.log("time out callback");e();c.g++;c.connect(a)},2E3);U3a(this,d)}else window.u2f?(this.a=this.c=!0,a(0)):(this.c=!1,a(8))};

The Network tab contains a request with POST request to https://accounts.google.com/jserror. The Params tab has the following:
context.location	https://accounts.google.com/signin/v2/challenge/sk
error	Element of 'transports' member of RegisteredKey 'null' is not a valid value for enumeration Transport.

Unless sign-in flow works for somebody on Linux, I think the bug needs to be reopen.