Google Online Account Two Factor with hardware key fails immediately

Bug #1733002 reported by Jonathan Brier
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Webkit
Fix Released
Medium
gnome-online-accounts
New
Unknown
gnome-online-accounts (Ubuntu)
Triaged
Low
Unassigned

Bug Description

The hardware key authentication two factor fails immediately with a web based retry dialogue when connecting a Google account to the online accounts in settings using a hardware key second factor.

Steps to reproduce:
1. Set Google Account to default to a hardware security key like a Yubikey or other FIDO standard key after having two factor authentication enabled on your Google Account.
2. Open Online accounts
3. Add a Google Account
4. Enter google email address
5. Enter google password
6. (this is the login flow of two factor, if default is the hardware key the error should appear).

Work around:
Choose use another method to authenticate: enter the authentication code and you will proceed.

Expectations were:
The ability to use the hardware key to authenticate as the second factor.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: gnome-control-center 1:3.26.1-0ubuntu5
ProcVersionSignature: Ubuntu 4.13.0-16.19-lowlatency 4.13.4
Uname: Linux 4.13.0-16-lowlatency x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.7-0ubuntu3.4
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri Nov 17 16:01:11 2017
EcryptfsInUse: Yes
ExecutablePath: /usr/bin/gnome-control-center
ProcEnviron:
 XDG_RUNTIME_DIR=<set>
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
SourcePackage: gnome-control-center
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
In , Ry5n (ry5n) wrote :

The FIDO Universal Second Factor (U2F) protocol is an open specification that was recently finalized. The FINAL spec can be downloaded here: https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009.zip

Revision history for this message
In , E-alice (e-alice) wrote :

Created attachment 279408
U2F request flow diagram.

U2F is beginning to see more wide-spread deployment, with Github being one notable example site that utilizes it. Currently, Chrome integrates support, but lower-level integration in WebKit would broadly increase the potential user base.

There exists a cross-platform (Windows, Linux, Mac OS X) C reference implementation, https://developers.yubico.com/libu2f-host/, supported by a manufacturer (Yubico) of U2F-compliant tokens. They also provide a test server for interactive experimentation (https://demo.yubico.com/u2f), reference server integration implementation, and cURL-able test endpoints.

This client (device host) reference implementation depends on: pkg-config, JSON-C, and HIDAPI for USB communication.

I very strongly desire U2F support both for my own site use, as well as for token-secured access to Github.

Revision history for this message
In , Ysuzuki-z (ysuzuki-z) wrote :

What is the difference from the Web Authentication[1,2]?

[1]: https://github.com/w3c/webauthn
[2]: https://w3c.github.io/webauthn/

Revision history for this message
Jonathan Brier (brierjon) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

affects: gnome-control-center (Ubuntu) → gnome-online-accounts (Ubuntu)
Changed in gnome-online-accounts (Ubuntu):
importance: Undecided → Low
Revision history for this message
Jonathan Brier (brierjon) wrote :

I believe I added the appropriate bugwatch to the upstream report: https://bugzilla.gnome.org/show_bug.cgi?id=791144

Changed in gnome-online-accounts:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Jiewen-tan (jiewen-tan) wrote :

(In reply to Yusuke Suzuki from comment #2)
> What is the difference from the Web Authentication[1,2]?
>
> [1]: https://github.com/w3c/webauthn
> [2]: https://w3c.github.io/webauthn/

WebAuthN is effectively FIDO 2.0. See Bug 181943 for status update regarding to WebAuthN.

Revision history for this message
In , John+webkit (john+webkit) wrote :

Does the work on WebAuthN contain FIDO 1.0 support as well? If not, this ticket is probably still valid on it's own.

Revision history for this message
In , Dwaite-b (dwaite-b) wrote :

FWIW, Edge has no intention to support U2F and only support WebAuthn.

The U2F JavaScript API unfortunately doesn't fully document how to get access to the objects needed to use the MessagePort and u2f interface API.

U2F supports CTAP1 devices, while WebAuthn supports CTAP1 and CTAP2 devices.

There is an extension for WebAuthn to work with existing U2F registrations (such as those created via another browser, or the Safari App Extension) with the new API, so that users can still authenticate when a site upgrades from using the U2F to WebAuthn javascript interfaces.

Revision history for this message
In , Jiewen-tan (jiewen-tan) wrote :

(In reply to john+webkit from comment #4)
> Does the work on WebAuthN contain FIDO 1.0 support as well? If not, this
> ticket is probably still valid on it's own.

WebAuthN will support CTAP1/U2F devices.

Revision history for this message
In , Jiewen-tan (jiewen-tan) wrote :

(In reply to David Waite from comment #5)
> FWIW, Edge has no intention to support U2F and only support WebAuthn.
>
> The U2F JavaScript API unfortunately doesn't fully document how to get
> access to the objects needed to use the MessagePort and u2f interface API.
>
> U2F supports CTAP1 devices, while WebAuthn supports CTAP1 and CTAP2 devices.
>
> There is an extension for WebAuthn to work with existing U2F registrations
> (such as those created via another browser, or the Safari App Extension)
> with the new API, so that users can still authenticate when a site upgrades
> from using the U2F to WebAuthn javascript interfaces.

Same as WebKit. I will leave this bug alone and re-scope it as [WebAuthN] Implement FIDO U2F extension.

Changed in gnome-online-accounts:
status: Confirmed → Unknown
Revision history for this message
In , Webkit-bug-importer (webkit-bug-importer) wrote :

<rdar://problem/48298273>

Revision history for this message
In , Jiewen-tan (jiewen-tan) wrote :

Created attachment 365249
Patch

Revision history for this message
In , Jiewen-tan (jiewen-tan) wrote :

Created attachment 365256
Patch

Revision history for this message
In , Jiewen-tan (jiewen-tan) wrote :

Comment on attachment 365256
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=365256&action=review

> Source/WebCore/ChangeLog:11
> + do in practice to avoid some unncessary steps of

unnecessary

> Source/WebCore/Modules/webauthn/fido/U2fCommandConstructor.h:65
> +WEBCORE_EXPORT Optional<Vector<uint8_t>> convertToU2fSignCommand(const Vector<uint8_t>& clientDataHash, const WebCore::PublicKeyCredentialRequestOptions&, const Vector<uint8_t>& keyHandle, bool isAppId = false);

I should explain the change in the ChangeLog: the checkOnly flag is never used and therefore is deleted.

> LayoutTests/http/wpt/webauthn/public-key-credential-create-success-hid.https.html:19
> + assert_not_exists(credential.getClientExtensionResults());

assert_not_exists(credential.getClientExtensionResults(), "appid");

> LayoutTests/http/wpt/webauthn/public-key-credential-create-success-local.https.html:33
> + assert_not_exists(credential.getClientExtensionResults());

Ditto.

> LayoutTests/http/wpt/webauthn/public-key-credential-create-success-u2f.https.html:15
> + assert_not_exists(credential.getClientExtensionResults());

Ditto.

> LayoutTests/http/wpt/webauthn/public-key-credential-get-success-local.https.html:36
> + assert_not_exists(credential.getClientExtensionResults());

Ditto.

> LayoutTests/http/wpt/webauthn/public-key-credential-get-success-u2f.https.html:18
> + assert_not_exists(credential.getClientExtensionResults());

Ditto.

Revision history for this message
In , Jiewen-tan (jiewen-tan) wrote :

Comment on attachment 365256
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=365256&action=review

> Source/WebCore/ChangeLog:15
> +

Need to add the new IDL file to MakeLists.txt to make GTK+ happy.

Revision history for this message
In , Bfulgham-b (bfulgham-b) wrote :

Comment on attachment 365256
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=365256&action=review

Nice work getting this together. r=me with the changes suggested, and assuming tests pass when you are done.

>> Source/WebCore/Modules/webauthn/fido/U2fCommandConstructor.h:65
>> +WEBCORE_EXPORT Optional<Vector<uint8_t>> convertToU2fSignCommand(const Vector<uint8_t>& clientDataHash, const WebCore::PublicKeyCredentialRequestOptions&, const Vector<uint8_t>& keyHandle, bool isAppId = false);
>
> I should explain the change in the ChangeLog: the checkOnly flag is never used and therefore is deleted.

Yes -- I got confused when I looked at the implementation, until I saw this note! :-)

> Source/WebKit/UIProcess/WebAuthentication/fido/U2fHidAuthenticator.cpp:214
> + response->appid = true;

Could this be:

response->appid = m_isAppId;

Revision history for this message
In , Jiewen-tan (jiewen-tan) wrote :

Comment on attachment 365256
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=365256&action=review

Thanks Brent for r+ this patch.

>> Source/WebKit/UIProcess/WebAuthentication/fido/U2fHidAuthenticator.cpp:214
>> + response->appid = true;
>
> Could this be:
>
> response->appid = m_isAppId;

Sure. Fixed.

Revision history for this message
In , Jiewen-tan (jiewen-tan) wrote :

Created attachment 365306
Patch for Landing

Revision history for this message
In , Jiewen-tan (jiewen-tan) wrote :

Comment on attachment 365306
Patch for Landing

cq+ since GTK+ bots are happy.

Revision history for this message
In , Commit-queue (commit-queue) wrote :

Comment on attachment 365306
Patch for Landing

Clearing flags on attachment: 365306

Committed r243193: <https://trac.webkit.org/changeset/243193>

Luke Faraone (lfaraone)
Changed in gnome-online-accounts (Ubuntu):
status: New → Triaged
Revision history for this message
DooMMasteR (winrootkit-w) wrote :

this is still broken…

Revision history for this message
Sebastien Bacher (seb128) wrote :

GNOME upstream pointed out webkitgtk as the place where the works needs to happen and to https://bugs.webkit.org/show_bug.cgi?id=143491 and a fix was recently commited, hopefully it means it's going to be resolved next cycle

Changed in webkit:
importance: Unknown → Medium
status: Unknown → Fix Released
Revision history for this message
Kiernan Nicholls (k5cents) wrote :

I just updated to 20.04 LTS today. In the Canonical press release for 20.04 they mention that FIDO support was integrated into this release: https://ubuntu.com/blog/ubuntu-20-04-lts-arrives

However, it still seems impossible to use a security key to authenticate adding a Google Account to GNOME via the Online Accounts section in settings. This is problematic given enrollment in Google's Advanced Protection Program necessitates the usage of a security key for such authentication (and prohibits alternatives like a one-time password).

Revision history for this message
Chris Boyle (chris-boyle-1978) wrote :

I can confirm that Ubuntu 20.04 suffers from the same issue. I'm still unable to link a Google Account due to being in Google's Advanced Protection Program, which requires a Security Key to authenticate. I'm able to authenticate in everything but Gnome's Online Accounts area.

Revision history for this message
Steven Jay Cohen (stevenjaycohen) wrote :

Confirming, it affects me at well (20.04).

Changed in gnome-online-accounts:
importance: Medium → Unknown
Changed in gnome-online-accounts:
status: Unknown → New
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.