Implement the FIDO Alliance u2f javascript API

NEW
Unassigned

Status

()

Core
DOM: Device Interfaces
--
enhancement
3 years ago
22 hours ago

People

(Reporter: Axel Nennker, Unassigned, NeedInfo)

Tracking

(Depends on: 6 bugs, {dev-doc-needed})

unspecified
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox ?)

Details

(Whiteboard: [parity-chrome] [extension available: https://addons.mozilla.org/firefox/addon/u2f-support-add-on/ ])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20140910030204

Steps to reproduce:

http://fidoalliance.org/specs/fido-u2f-javascript-api-v1.0-rd-20140209.pdf
(Reporter)

Comment 1

3 years ago
There is an open source extension (BSD-License) for Chrome by Google here:
https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/u2f-api.js
OS: Windows 7 → All
Hardware: x86_64 → All
Google announced Chrome support this morning:

http://googleonlinesecurity.blogspot.com/2014/10/strengthening-2-step-verification-with.html
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [parity-chrome]
(Reporter)

Comment 3

3 years ago
The spec was updated this month.
https://fidoalliance.org/specifications/download
Especially
https://fidoalliance.org/specs/fido-u2f-v1.0-rd-20141008.zip

I guess it is time to create some more bugs and use this one to track them.

How difficult is usb access in Firefox? Support on different platforms will bind developer resources.

I would like to support other hardware as authenticators like SIM cards on Firefox for Android and B2G too.
We (Telekom Innovation Laboratories) are working on the Secure Element API in Firefox (B2G).
This bug is no dependency on u2f but just for info: 
https://bugzilla.mozilla.org/show_bug.cgi?id=879861

The Chromium code is here:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/cryptotoken/

Is somebody attending W3C TPAC? Sadly I am not attending.
http://www.w3.org/2014/11/TPAC/
FIDO and WebCrypto HW Tokens will be discussed in the WebCrypto session
http://lists.w3.org/Archives/Public/public-webcrypto/2014Sep/0026.html

Another good event to meet interested parties is IIW in Mountain View.
http://www.internetidentityworkshop.com/
Yubico, FIDO Alliance and Googlers are usually there.
(Reporter)

Comment 4

3 years ago
Dependency to WebUSB? bug 674718
Although the API https://wiki.mozilla.org/WebAPI/WebUSB seems quite highlevel and
this search
http://mxr.mozilla.org/mozilla-central/search?string=attachdevice
yields zarro results (yet).

The Chrome code for u2f usb handling
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/cryptotoken/usbgnubbydevice.js
uses: (https://developer.chrome.com/apps/usb)
chrome.usb.getDevices
chrome.usb.listInterfaces
chrome.usb.bulkTransfer
chrome.usb.closeDevice
chrome.usb.claimInterface
chrome.usb.releaseInterface
chrome.usb.requestAccess or chrome.usb.openDevice (depending on whether it is ChromeOS)

I think that we need something like bug 674718. Probably more.
Although exposing webusb to content is a currently unsolved permission/priviledge problem. So I would like to see webusb (or similar) implemented but first only for internal browser use and addons.
I think that tying this to WebUSB (and thus bug 674718) isn't desirable.  While they share some things in common, I'm wary of having some of the potential security challenges that come with WebUSB associated with U2F, which is explicitly a security-sensitive system.

Even if we end up leveraging some of the same underlying code in terms of interacting with USB devices, I don't think that U2F should end up leveraging WebUSB directly.
(Reporter)

Comment 6

3 years ago
Created attachment 8521381 [details] [diff] [review]
u2f-webidl.patch

Copying the webidl fragments from the spec did not work
https://fidoalliance.org/specs/fido-u2f-javascript-api-v1.0-rd-20141008.pdf

One thing is that the data type "int" is not legal webidl. 
I replaced it with "unsigned long" and contacted the spec authors.
Other issues are that "SignRequest[]" does not go well down the throat of our webidl.parser. 
I replaced those by sequence<Signrequest> which according to the ECMAScript binding should be an array.
http://www.w3.org/TR/WebIDL/#es-sequence

The W3C webidl checker has more comments but those should be addressed by the spec authors too.
http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Faxel.nennker.de%2FU2F.webidl&output=html

Comment 7

3 years ago
I wanted to post the link to the video of the presentation from Yubico.  This is a useful backgrounder for anyone who needs it.  https://air.mozilla.org/fido-u2f/
I was just considering upgrading my Yubikey to their new FIDO U2F Security Key (https://www.yubico.com/products/yubikey-hardware/fido-u2f-security-key/#toggle-id-3) but looks like adding this support is a blocker for me personally. 

So I guess I will subscribe and hope for support in the near future :)
Comment hidden (advocacy)

Comment 10

3 years ago
We have published a low-level C library for talking to U2F devices over USB -- https://developers.yubico.com/libu2f-host/ -- and we can relicense it as needed if you want to use it.  What remains is to work on the JavaScript side, which is something we don't have expertise in but I believe you already started on that.  If I can help with anything, including devices for testing, I'd be happy to help out.
(Reporter)

Comment 11

3 years ago
(In reply to Simon Josefsson from comment #10)
> We have published a low-level C library for talking to U2F devices over USB
> -- https://developers.yubico.com/libu2f-host/ -- and we can relicense it as
> needed if you want to use it.  What remains is to work on the JavaScript
> side, which is something we don't have expertise in but I believe you
> already started on that.  If I can help with anything, including devices for
> testing, I'd be happy to help out.

Thanks for the library code. Regarding the license please see here:
https://www.mozilla.org/MPL/license-policy.html#Licensing_of_Third_Party_Code
It appears to me that Yubico's license for libu2f-host is not compatible with Mozilla's license.
If Yubico could relicense the libu2f-host code to Mozilla 2.0 that would be great.
Mozilla's licensing team probably has to be involved anyway. Please file a licensing bug here:
https://bugzilla.mozilla.org/enter_bug.cgi?format=guided#h=dupes|mozilla.org|Licensing

Regarding building the library: I develope under Ubuntu and "./configure" fails with:
./configure: line 5259: syntax error near unexpected token `win32-dll'
./configure: line 5259: `LT_INIT(win32-dll)'

Which is probably no blocker because the code has to be turned into a component/service as decribed here:
https://developer.mozilla.org/en-US/docs/Adding_XPCOM_components_to_Mozilla_build_system

-Axel
(Reporter)

Comment 12

3 years ago
Created attachment 8537208 [details] [diff] [review]
Bug1065729.patch

An intermediate state that contains a ton of gruft from the identity work.
I chose the Identity.webidl and stuff because Identity has a similare API that contains no DOMEvents.

Next steps:
- put libu2f-host into XPCOM component
- send messages to java on Android
- if the Secure Element API is availabe (B2G) use u2f authenticator on SE
- return results to content script. My tries resulted in an exception when the content script accesses the priviledged error object.
Attachment #8521381 - Attachment is obsolete: true

Comment 13

3 years ago
We discussed applicability of libu2f-host a couple of days ago -- while we are happy to relicense it (and will probably do it just to get that issue out of the way) there are other aspects of it that will need more work: for example, currently the library is synchronous, and busy-loops waiting for U2F communications from the device.  I'm pretty sure this won't work for you.  We are adding a small tweak to add a timeout to do the looping, so the application regains control and can invoke the library again, when needed.  However, this may not be sufficient either -- do you require fully asynchronous libraries?  Alternatively, if you put our library in a separate thread it may work.

Generally, we are happy to consider fixes to libu2f-host that makes it more usable for you.

Comment 14

3 years ago
> Regarding building the library: I develope under Ubuntu and "./configure"
> fails with:
> ./configure: line 5259: syntax error near unexpected token `win32-dll'
> ./configure: line 5259: `LT_INIT(win32-dll)'

Sounds like you need libtool, or possibly a newer version of libtool.

/Simon

Comment 15

3 years ago
If I can help in any way, let me know. I have a new U2F device I can test with.

/Timothy
Comment hidden (me-too)
(Reporter)

Comment 17

3 years ago
Is it true that even if Yubico relicenses libu2f-host we still might have a problem because of libu2f-host uses libusb which is LGPL?
https://bugzilla.mozilla.org/show_bug.cgi?id=1115685

In https://bugzilla.mozilla.org/show_bug.cgi?id=webusb :gerv says that it is ok to use libusb if we link a dynamic library. 

So we have to collect libusb.dll, libusb.so for all supported platforms and put them into the mozilla-central tree somewhere, right?
Comment hidden (me-too)
Comment hidden (me-too)
Comment hidden (me-too)
Comment hidden (me-too)

Comment 22

3 years ago
duplicate
I have been using u2f for a while now and have a few commercial devices I can use to test the implementation of u2f in Firefox. Please include me in testing.
Comment hidden (me-too)
Comment hidden (me-too)
(Reporter)

Comment 25

3 years ago
1)
I noticed that Yubico's demo page uses window.u2f while the current patch uses navigator.u2f ...
http://demo.yubico.com/start/u2f/neo

The FIDO spec about the javascript API does not specify where the API lives.

Not sure what the "standard" is or will be.

2)
My own test page http://axel.nennker.de/testu2f.html is currently bonked because I try to get a challenge from http://demo.yubico.com/wsapi/u2f/enroll?username=jas&password=foo but that server does not send a CORS header so the patched Firefox forbids the request. 
Using CORS does not make terrible sense but it is only a test page...
Using Yubico's demo page http://demo.yubico.com/start/u2f/neo seems to make more sense.

3)
Status: Played with libu2f-host, libusb, libhid on Ubuntu.
Looks like libu2f-host can be reimplemented in javascript and send the APDUs through libhid
(Reporter)

Comment 26

3 years ago
Created attachment 8548780 [details] [diff] [review]
Bug1065729.patch

Suddenly the init method is not allowed to return something and when this happens the browser code crashes Firefox on purpose here:
http://mxr.mozilla.org/mozilla-central/source/dom/bindings/BindingUtils.cpp#2164

Removed the preferences check and do not return null.
Attachment #8537208 - Attachment is obsolete: true

Comment 27

3 years ago
FWIW, libu2f-host 0.0.3 is relicensed under LGPLv2+.

Comment 28

3 years ago
Axel, re #25:

1) The location of the API is left unspecified until it is a proper web API. It's also left browser specific how to obtain the MessagePort to the U2F client, but if navigator.connect [1] matures into a standard, that would be a cross-browser way to get one.

The motivation for the two layered API is similar to [2]. The interface between the two layers is fully defined in [3], which is BSD licensed and so should be reusable by Mozilla.

[1] http://mkruisselbrink.github.io/navigator-connect/
[2] https://github.com/dglazkov/tubes
[3] https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/u2f-api.js


2) I can help with adjusting u2fdemo.appspot.com to accommodate FF testing. That website serves as a model for other server implementations, so it'd be awesome if it supports FF.


3) Chrome's implementation is nearly all in JS. The APDUs are constructed and sent from [4] and [5], with the hid transport defined in [6] (which uses chrome.hid [7])

[4] https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/gnubby.js
[5] https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/gnubby-u2f.js
[6] https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/hidgnubbydevice.js
[7] https://developer.chrome.com/apps/hid

Again, this is all under a BSD style license (https://developers.google.com/open-source/licenses/bsd)


(The U2F extension on GitHub is very similar to the one built into Chrome - which you can also browse here: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/cryptotoken/ )

Feel free to ping me if I can assist in other ways.
Keywords: dev-doc-needed
FWIW, Yubico is giving me a code to share with 200 Nightly Testers anyone who would like to test the functionality when it lands please request a code the post is up on Planet or ping me on IRC.

Comment 30

3 years ago
(In reply to Benjamin Kerensa [:bkerensa] from comment #29)
> FWIW, Yubico is giving me a code to share with 200 Nightly Testers anyone
> who would like to test the functionality when it lands please request a code
> the post is up on Planet or ping me on IRC.

what exactly does the code do?
(In reply to Timothy Hamlett from comment #30)
> (In reply to Benjamin Kerensa [:bkerensa] from comment #29)
> > FWIW, Yubico is giving me a code to share with 200 Nightly Testers anyone
> > who would like to test the functionality when it lands please request a code
> > the post is up on Planet or ping me on IRC.
> 
> what exactly does the code do?

Allows them to have a free U2F Yubikey but they are all gone now :)

Comment 32

3 years ago
Has much progress been made on an implementation using native libraries?  As an experiment I've written an extension which instead uses js-ctypes to discover and communicate directly with U2F devices using Windows APIs.  Currently it just opens a channel and sends a "wink" command (which incidentally seems to be broken on the Yubico U2F keys I have) as a proof-of-concept, but I've been working in my spare time on turning it into a more useful implementation.  I can finish tidying up and releasing the code if it would be useful to anyone, I'm not sure how difficult a similar approach would be for Mac and Linux but I believe it should be possible.
(Reporter)

Comment 33

3 years ago
(In reply to Mike Nicholls from comment #32)
> Has much progress been made on an implementation using native libraries?  As
> an experiment I've written an extension which instead uses js-ctypes to
> discover and communicate directly with U2F devices using Windows APIs. 
> Currently it just opens a channel and sends a "wink" command (which
> incidentally seems to be broken on the Yubico U2F keys I have) as a
> proof-of-concept, but I've been working in my spare time on turning it into
> a more useful implementation.  I can finish tidying up and releasing the
> code if it would be useful to anyone, I'm not sure how difficult a similar
> approach would be for Mac and Linux but I believe it should be possible.

There is not much progress from my side. I am doing this in my pet-project-time too.
My plan is to put libusb under mozilla_centra/ipc/ as mozilla_central/ipc/libusb and get the mozilla build-system to build the libusb-library for the different platforms.
That library can then be used to implement an u2f-usb-handler with a js2c bridge to libusb.
I think the u2f-usb-handler api should not export the whole usb glory but something like:

dictionary UsbAuthenticator {long device; long vendorId; long productId; }
callback ListAuthenticatorsCallback = void(ListDevicesResponse or Error) response);

[JSImplementation="@mozilla.org/u2f/usbhandler;1", NoInterfaceObject, ChromeOnly]
interface U2fUsbHandler {
 listauthenticators(ListOption options, ListAuthenticatorsCallback listcallback);
 open(Authenticator authenticator, OpenAuthentitcatorCallback openCallback);
 close(Authenticator authenticator, CloseAuthenticatorCallback closeCallback);
 send(U2fRequest requestData, SendRequestCallback sendCallback);
};

The U2F implementation as a whole should allow bluetooth, SIM and NFC too.
E.g. 
- Fennec should look for U2F SIM support. 
- Fennec on a NFC capable device should read NFC-Authenticators.
- FirefoxOS should support SIM and NFC authenticators.

Comment 34

3 years ago
Maybe Firefox os should support U2F with USB OTG (when support of OTG will be done => https://bugzilla.mozilla.org/show_bug.cgi?id=1029961 )
Comment hidden (obsolete)
Comment hidden (me-too)
Comment hidden (me-too)

Comment 38

2 years ago
Btw, it is not advisable to buy right now an U2F key right now (Yubico, Plug-Up, ...) because the FIDO 2.0 specification is on the way, that Windows 10 will probably support it, Chrome OS will update its FIDO support to the next FIDO 2.0 specification. So, it's better to wait and buy a FIDO 2.0 U2F device. Right now, it's like 5 years ago when you were buying some devices with USB 2.0 port, whereas USB 3.0 was released: manufacturers are happy to destock their obsolete technology, but not the consumers. So, for FIDO 2.0, you have to wait more than 2 months, before you could buy one FIDO U2F 2.0 device.

Comment 39

2 years ago
HLFH, I can't find any documentation or discussion about FIDO 2.0 specification, can you provide some reference?

Comment 40

2 years ago
(In reply to HLFH from comment #38)
> Btw, it is not advisable to buy right now an U2F key right now (Yubico,
> Plug-Up, ...) because the FIDO 2.0 specification is on the way, that Windows
> 10 will probably support it, Chrome OS will update its FIDO support to the
> next FIDO 2.0 specification. So, it's better to wait and buy a FIDO 2.0 U2F
> device. Right now, it's like 5 years ago when you were buying some devices
> with USB 2.0 port, whereas USB 3.0 was released: manufacturers are happy to
> destock their obsolete technology, but not the consumers. So, for FIDO 2.0,
> you have to wait more than 2 months, before you could buy one FIDO U2F 2.0
> device.

a) FIDO 2.0 is referenced in this post only. No official information posted anywhere yet.
b) Are you implying that all U2F devices made to date will become obsolete and not supported? I.e. will 2.0 be not backward compatible?
(Reporter)

Comment 41

2 years ago
#offtopic
I think that devices / authenticators will not change with v2.

(In reply to cserpentis from comment #40)
> (In reply to HLFH from comment #38)
> > Btw, it is not advisable to buy right now an U2F key right now (Yubico,
> > Plug-Up, ...) because the FIDO 2.0 specification is on the way, that Windows
> > 10 will probably support it, Chrome OS will update its FIDO support to the
> > next FIDO 2.0 specification. So, it's better to wait and buy a FIDO 2.0 U2F
> > device. Right now, it's like 5 years ago when you were buying some devices
> > with USB 2.0 port, whereas USB 3.0 was released: manufacturers are happy to
> > destock their obsolete technology, but not the consumers. So, for FIDO 2.0,
> > you have to wait more than 2 months, before you could buy one FIDO U2F 2.0
> > device.
> 
> a) FIDO 2.0 is referenced in this post only. No official information posted
> anywhere yet.
> b) Are you implying that all U2F devices made to date will become obsolete
> and not supported? I.e. will 2.0 be not backward compatible?

Comment 42

2 years ago
a) FIDO 2.0 has not been released yet, FIDO 2.0 Specification is a draft. We could expect the final release before the end of 2015. In fact, FIDO Alliance has a FIDO 2.0 Technology Working Group: they work for FIDO 2.0 since December 2014. The co-chairmen and the affiliate members are working on it: Anthony Nadalin, Microsoft, Sampath Srinivas, Google, Ramesh Kesanupalli, Nok Nok Labs. As seen here: https://fidoalliance.org/working-groups/ ; so it's a subset of the FIDO Alliance members, and they have access to the current working drafts of the FIDO 2.0.

According to Brett McDowell, executive director of the FIDO Alliance, FIDO 2.0 should be released before Fall. If we are optimistic, FIDO 2.0 Final will be released at the same time as the General Availability of Windows 10 that will support FIDO 2.0 (https://blogs.windows.com/business/2015/02/13/microsoft-announces-fido-support-coming-to-windows-10/), so at the end of July. If we are not optimistic, FIDO 2.0 could be released in late Q4 2015. https://groups.google.com/a/fidoalliance.org/forum/#!topic/fido-dev/rhiY5UWF_N0

Google is actively working for the FIDO 2.0 specification. As soon as it will be released, Google Chrome will update its FIDO support to the 2.0 final specification. It has been confirmed at the European Identity Conference 2015, one month ago.

b) Thanks for the question. As seen on Twitter, even Yubico does not know if the U2F FIDO 1.0 devices will become obsolete, if just a firmware update could update it to the FIDO 2.0 spec, or if 2.0 will be entirely backward-compatible. https://twitter.com/shanytc/status/578231973656850432

So because Yubico does not know, I asked the question on the FIDO Dev community group. We could expect a answer before the end of the week. IMHO, U2F 1.0 devices will become obsolete, but we need confirmation from the executive director of the FIDO Alliance. https://groups.google.com/a/fidoalliance.org/forum/#!topic/fido-dev/zvS9BM8HXLQ

Comment 43

2 years ago
(In reply to HLFH from comment #42)
> b) Thanks for the question. As seen on Twitter, even Yubico does not know if
> the U2F FIDO 1.0 devices will become obsolete, if just a firmware update
> could update it to the FIDO 2.0 spec, or if 2.0 will be entirely
> backward-compatible.

Thanks for all the information. However I just wanted to comment that upgrading firmware on Yubico devices is not possible (see https://www.yubico.com/faq/upgrade-yubikey-firmware/) so if 2.0 it isn't backwards compatible, people who have a 1.0 device will need to purchase a new one if they need 2.0 support.

Comment 44

2 years ago
Ok, there is reply made by FIDO person for HLFH
"FIDO 2.0 is not being designed to render anything we've done before obsolete.  On the contrary, it is designed to spread FIDO to more client systems in the ecosystem by means of specific optimizations that make it easier for platforms (i.e. operating systems, web browsers, etc.) to bake in FIDO support "out of the box", enabling our vision of ubiquitous support for FIDO authentication.    Although some of the required optimizations may require the actual wire protocol to be different in 2.0, our strategy for ensuring backwards compatibility is tied to our recently launched FIDO Certification Program.  Going forward server vendors/implementers will be incentivized to provide backward compatibility for all FIDO Certified client devices, UAF 1.X, U2F 1.X, and 2.0.  This enables the 2.0 specifications to be fit-for-purpose to enable native platform support while helping to ensure full backward compatibility in the market going forward for all FIDO Certified authenticators and clients/browsers.

As to your question about implementers pushing out updates to their 1.X implementations to make them 2.0 compliant, this is really up to the implementation, by each FIDO vendor: FIDO Device vendors can decide to build their FIDO devices in a way that allows for upgrading the firmware to support 2.0.  

 	Brett McDowell"

I suppose this means "1.0 devices will still be supported"?

Comment 45

2 years ago
I think FIDO support in Firefox OS would be more interesting than a desktop implementation.

Comment 46

2 years ago
(In reply to V. Korn from comment #44)
> 
> I suppose this means "1.0 devices will still be supported"?

First, I want to thank everyone involved in this effort to FIDO-enable FireFox and/or FireFox OS.  It is a great start having this standard supported in Chrome, but users need choice and it is great to think FireFox might be browser platform #2 to ship with support for FIDO U2F 1.0.  

To answer the question about 1.0 device support, I want to offer my full endorsement for U2F 1.0 implementation in FireFox now.  Not only will U2F 1.0 exist after FIDO 2.0 is out, but the implementation of U2F 1.0 in Mozilla's platforms now, will help the 2.0 implementation in the future as there should be quite a bit of code re-use.

So "YES", the strategy within FIDO Alliance is to foster the growth of this ecosystem starting with 1.0 clients, servers, and devices then expand that ecosystem through broader platform support with 2.0 and backwards compatibility for 1.0 clients and devices baked into FIDO server implementations that can support all previously certified FIDO 1.0 devices.

Hope that helps,
--Brett
Comment hidden (me-too)
Comment hidden (off-topic)

Comment 49

2 years ago
+1 to not waiting for 2.0 APIs.  The U2F use case is independently valuable and likely to endure even as the more sophisticated APIs take shape and see deployment.  It is also relatively trivial for service providers to implement, but the motivation to do so is substantially less so long as its reach is Chromium-only.  A Firefox implementation would be a really big deal for organizations currently on-the-fence about adding U2F support alongside things like SMS, Google Authenticator and the like.

Comment 50

2 years ago
(In reply to Brad Hill from comment #49)
> +1 to not waiting for 2.0 APIs.  The U2F use case is independently valuable
> and likely to endure even as the more sophisticated APIs take shape and see
> deployment.  It is also relatively trivial for service providers to
> implement, but the motivation to do so is substantially less so long as its
> reach is Chromium-only.  A Firefox implementation would be a really big deal
> for organizations currently on-the-fence about adding U2F support alongside
> things like SMS, Google Authenticator and the like.

Its not only organizations(and its users) who can use U2F to get additional security. For example plugins to implement U2F in Joomla CMS (https://www.akeebabackup.com/download/yubikey/yubikey-2-0-0.html) and WordPress already made. This means, that possible area of U2F use maybe much wider then it looks.
Comment hidden (advocacy)
Comment hidden (me-too)
Comment hidden (me-too)

Comment 54

2 years ago
Google just announced, that Google Apps will use this. http://googleappsupdates.blogspot.com/2015/06/a-special-offer-and-new-controls-for.html
Comment hidden (advocacy)
Comment hidden (me-too)

Comment 57

2 years ago
I would also be rather excited to see this feature added to Firefox. We are considering an enterprise rollout of mandatory U2F for our SSO system at my employer (Square), so if Firefox doesn't support it this would entail banning employees from using Firefox.

I'd hate to see that!

Comment 58

2 years ago
Totally serious, with the best intentions: since the main objective of the FIDO Alliance is to make U2F successful, why don't they just hire a developer for 1-2 months to add support on Firefox, which is probably the biggest gain they can have for the money spent? (I ask here because surely someone from FIDO is reading this thread).

Comment 59

2 years ago
(In reply to riccardo from comment #58)
> Totally serious, with the best intentions: since the main objective of the
> FIDO Alliance is to make U2F successful, why don't they just hire a
> developer for 1-2 months to add support on Firefox, which is probably the
> biggest gain they can have for the money spent? (I ask here because surely
> someone from FIDO is reading this thread).

What is concerning for me is that this is not assigned and it is not clear to me who to contact even if I would want to contribute to this effort.
(In reply to Gerhard Poul from comment #59)
> (In reply to riccardo from comment #58)
> > Totally serious, with the best intentions: since the main objective of the
> > FIDO Alliance is to make U2F successful, why don't they just hire a
> > developer for 1-2 months to add support on Firefox, which is probably the
> > biggest gain they can have for the money spent? (I ask here because surely
> > someone from FIDO is reading this thread).
> 
> What is concerning for me is that this is not assigned and it is not clear
> to me who to contact even if I would want to contribute to this effort.

It's not assigned because we have nobody working on it.  (To be honest, assignment isn't even a guarantee somebody is working on it, or that the time-frame is relevant, etc.)  More specifically, this doesn't feature in any web platform or Fennec roadmap that I'm aware of.

However, I am interested in this ticket, watch the discussion (which lately is +1s -- valuable feedback but not technically actionable), and worked a little bit with Axel Nennker on an implementation, which fizzled.  I can help guide some of the integration into Fennec.  In general, mobile-firefox-dev [1] is a great place to start discussion, ask for help, etc.

The concrete proposed way to make this happen on Android has a lot of pre-requisites that I can't help with: landing a USB library into Gecko, for example, or implementing WebUSB.  It would help me to know if this could be done purely in Android Java.

[1] https://mail.mozilla.org/listinfo/mobile-firefox-dev
Flags: needinfo?(gpoul)
Comment hidden (me-too)
Nick is correct that there is nobody assigned to work on FIDO right now, at least in terms of MoCo.

Beyond issues of resource prioritization, the major barrier (for me at least) is that it's not clear that the current U2F API is at the right level of abstraction.  APIs that get added to the web have to have a good deal of longevity, because it is very hard to remove features from the web.  The current U2F API is totally specific to FIDO, and as nice as FIDO is, I'm not totally convinced that it's a forever solution.  (I think there is a solution to be found here.  Tanvi and I are starting to look at whether the proposed Credentials API might be a sensible framework.)

If people would like to contribute in the mean time, the main thing that is lacking in Gecko at the moment is a USB HID API.  That's the channel that FIDO uses to talk to hardware, and Gecko doesn't currently expose it.  If someone were to build an HID API that were accessible from privileged JS, then I think it would be straightforward to build an extension to do FIDO in the short run (e.g., by porting the Chrome extension), and it would help any more direct implementation of FIDO in the long run.
(In reply to Richard Barnes [:rbarnes] from comment #62)
> Nick is correct that there is nobody assigned to work on FIDO right now, at
> least in terms of MoCo.
> 
> Beyond issues of resource prioritization, the major barrier (for me at
> least) is that it's not clear that the current U2F API is at the right level
> of abstraction.  APIs that get added to the web have to have a good deal of
> longevity, because it is very hard to remove features from the web.  The
> current U2F API is totally specific to FIDO, and as nice as FIDO is, I'm not
> totally convinced that it's a forever solution.  (I think there is a
> solution to be found here.  Tanvi and I are starting to look at whether the
> proposed Credentials API might be a sensible framework.)

I know little about the Credentials API but think that it looks like a good direction to pursue.

> If people would like to contribute in the mean time, the main thing that is
> lacking in Gecko at the moment is a USB HID API.  That's the channel that
> FIDO uses to talk to hardware, and Gecko doesn't currently expose it.  If
> someone were to build an HID API that were accessible from privileged JS,
> then I think it would be straightforward to build an extension to do FIDO in
> the short run (e.g., by porting the Chrome extension), and it would help any
> more direct implementation of FIDO in the long run.

I agree with this assessment (as I hinted at in https://bugzilla.mozilla.org/show_bug.cgi?id=1065729#c60).  I'd like to offer (again) my help making a Android-only, Java-only solution happen.  If there's a way to do this in an Android App, there's easy progress to be made.

Comment 64

2 years ago
(In reply to Richard Barnes [:rbarnes] from comment #62)
> Nick is correct that there is nobody assigned to work on FIDO right now, at
> least in terms of MoCo.
> 
> Beyond issues of resource prioritization, the major barrier (for me at
> least) is that it's not clear that the current U2F API is at the right level
> of abstraction.  APIs that get added to the web have to have a good deal of
> longevity, because it is very hard to remove features from the web.  The
> current U2F API is totally specific to FIDO, and as nice as FIDO is, I'm not
> totally convinced that it's a forever solution.  (I think there is a
> solution to be found here.  Tanvi and I are starting to look at whether the
> proposed Credentials API might be a sensible framework.)

Some might also argue FIDO has architectural defects that should be addressed. The design is effectively the TLS equivalent of RSA-key transport, where attackers can use a privileged position for the Chess Grandmaster attack. The adversary can just shepherd packets between the user and the server and the protocol is no wiser. (And others would argue that's a feature).

Comment 65

2 years ago
(In reply to Jeffrey Walton from comment #64)
> Some might also argue FIDO has architectural defects that should be
> addressed. The design is effectively the TLS equivalent of RSA-key
> transport, where attackers can use a privileged position for the Chess
> Grandmaster attack. The adversary can just shepherd packets between the user
> and the server and the protocol is no wiser. (And others would argue that's
> a feature).

This is mitigated by TLS channel binding. See: http://www.browserauth.net/

Comment 66

2 years ago
BTLE for U2F was recently announced:
https://fidoalliance.org/fido-alliance-equips-u2f-for-mobile-and-wireless-applications/

If there is nobody to work on USB support in FF, maybe an easier first step would be to re-use the internal plumbing that supports https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API and build a U2F API on top of that.

Comment 67

2 years ago
(In reply to Jeffrey Walton from comment #64)
> Some might also argue FIDO has architectural defects that should be
> addressed.

While every claim you make is technically true, those are problems that are common to similar standards, and can be addressed by other IETF WGs as a layered approach. For example, U2F should work well in conjunction with whatever origin-bound certificate solution is produced by the Tokbind WG.

U2F definitely doesn't solve everything out of the gate, but I think it's disingenuous to suggest it has to.
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)

Comment 71

2 years ago
Logistically, there are several manufacturers making FIDO U2F tokens: Yubikey, Hyperfido, Nitrokey. FIDO might not be a consensus based standards organization as some would wish, but this doesn't detract from the intrinsic technical merit of the U2F protocol. There is no silver bullet for authentication. Certainly passwords are here to stay. But we have to start giving people some better option. From an economic perspective, U2F offers a way for domains to adopt a token that they don't have to issue--people can buy one online from their favorite retailer. This overcomes one of the biggest hurdles to deployment--being able to use your token as a credential for more than one website. Also Google 2FA already supports U2F (you can register one or more tokens), and Microsoft also seems supportive. Whatever you think of these two giants, their blessing helps to provide some adoption critical mass.

A firefox plugin (or even native support) for U2F would help move the ball forward in a small but meaningful way.
Comment hidden (obsolete)

Comment 73

2 years ago
Agree with @Tom, I think that the FIDO v1 vs v2 might be off-topic as well.  It sounds like an incremental upgrade and since we are repurposing Chrome's code for the core logic, I seriously doubt v2 will require that much additional labor.  I would support keeping v1 behind a config flag so as to remove any concerns regarding long-term maintenance.

Comment 74

2 years ago
Dropbox added support for U2F (to their >400M users) today: https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
(Reporter)

Comment 75

2 years ago
To move forward with this bug I suggest to split work and create new bugs for Android and FirefoxOS.
Core/common stuff like webidl can stay here or move to a separate new bug.
libusb/libhid stuff can stay here or move to a separate new bug.

-  Implement the FIDO Alliance u2f javascript API on Android
   + forward parameters to java side
   1 send parameters through NFC to token, read response
   2 send parameters through BTLE to token, read response
   3 send parameters through openmobile API, read response
   + send response back to content script

-  Implement the FIDO Alliance u2f javascript API for FirefoxOS 
   + forward parameters to java side
   1 send parameters through NFC to token, read response
   2 send parameters through Bluetooth, read response
   3 send parameters through SecureElement API, read response
   + send response back to content script

Comment 76

2 years ago
Github added support for U2F today:

https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication

Comment 77

2 years ago
Microsoft is currently working on adding U2F to Edge ('In Development'):
https://dev.modern.ie/platform/status/fido20webapis/

Comment 78

2 years ago
Yubico has a special offer for github users: https://www.yubico.com/github-special-offer/

Please grab a key and implement the support on FireFox ;-)
Comment hidden (off-topic)
Comment hidden (advocacy)
(In reply to malu_pigi from comment #80)
> It have been about a year now since this bug (feature request) was created,
> any updates on the current developments? Do you (Firefox) have any estimate
> on when this feature might land to the stable release users?

Sadly I have no information here, other than that I am not aware of any group inside of Mozilla prioritizing this.

billm,andym: could one of you comment on whether the Web Extensions APIs will expose USB access to extensions, and perhaps on what timeline?  That would allow interested fishers to catch their own fish.

Contributions gladly accepted!
Flags: needinfo?(wmccloskey)
Flags: needinfo?(amckay)
It would be nice to be able to do this as an extension. Chrome has an app API for USB:
https://developer.chrome.com/apps/usb
We don't have any plans to implement it though. So far I haven't seen demand for USB outside of this bug.
Flags: needinfo?(wmccloskey)

Comment 83

2 years ago
Well, I know of one manufacturer who offers a webapp to reprogram networking-gear attached via USB. They use Chrome for that since they offer their WebUSB-API. Afaik it's an open and published standard? And if Firefox were to offer that USB-API as well ... :-)
(In reply to Stefan Neufeind from comment #83)
> Well, I know of one manufacturer who offers a webapp to reprogram
> networking-gear attached via USB. They use Chrome for that since they offer
> their WebUSB-API. Afaik it's an open and published standard? And if Firefox
> were to offer that USB-API as well ... :-)
See bug 674718 for that API.
Comment hidden (me-too)
Comment hidden (me-too)

Updated

2 years ago
Flags: needinfo?(amckay)
Comment hidden (advocacy)
Comment hidden (advocacy)
Comment hidden (spam)

Comment 90

2 years ago
My new U2F token just arrived from this promotion from Github and Yubikey announced three weeks ago:
https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication

The setup instructions are here:
https://www.yubico.com/support/documentation/how-to-use-your-yubikey-with-github/

The first bullet under “Required Pieces for Setting Up Your U2F-Compliant YubiKey with GitHub” says “Latest version of Google Chrome browser.”

I prefer Firefox mainly for reasons of https://www.mozilla.org/en-US/about/manifesto/ but this turn of events is concerning.

I will subscribe to this issue and leave the yubikey in a drawer for now, looking forward to the day Firefox supports U2F authentication.
Comment hidden (advocacy)
Comment hidden (advocacy)

Comment 93

2 years ago
I decided to redirect my annual mozilla donation to the bounty : 
https://www.bountysource.com/issues/10401143-implement-the-fido-alliance-u2f-javascript-api
If half of the subscribers of this bug would do that, they have and incentive to prioritize.
Comment hidden (off-topic)
Comment hidden (advocacy)
Comment hidden (advocacy)
Please leave bug comments for technical discussion of this issue.  Bugzilla is not the right place to debate what Mozilla should do.

Mailing lists are a better place to discuss use cases, priorities, and such. For example, the dev-platform or firefox-dev lists seem appropriate here.
Comment hidden (me-too)
Comment hidden (advocacy)

Comment 100

2 years ago
I just published experimental extension that allow to use yubico as second factor in u2f, it can be found here: https://addons.mozilla.org/pl/firefox/addon/u2f-support-add-on/ (i also made source code public and it can seen here: https://github.com/prefiks/u2f4moz)

This extension was create in just couple afternoons, and it was not tested much, and it was almost exclusively used on linux, so macos and windows versions could still have some problems.

It should work on http://demo.yubico.com/u2f, and if you spoof user agent to present your browser as chrome, you can also use it on dropbox, doesn't work with github - code on that page works only in chrome.

People brave enough to test it, please report issues as github tickets.
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)

Comment 105

2 years ago
1) First, I put 50$ on this bounty, I will convince other people to do so... but please, 
everyone, let's all participate ! (there is still works to do!)

https://www.bountysource.com/issues/10401143-implement-the-fido-alliance-u2f-javascript-api

2) Regarding the first beta plugin, thanx Pawel ! that's a great start !
On http://demo.yubico.com/u2f, it kind-of-works with Yubico tokens but not correctly with tokens from Plugup/happlink or from Neowave that are not supposed to be present from the beginning (no button). I will make further tests and reports with other products too through github tickets like Pawel Chmielowski asked.
Comment hidden (off-topic)
Comment hidden (off-topic)
Please take further discussion of the extension elsewhere, this bug is for discussing a native implementation in Firefox.

Comment 109

2 years ago
@pawel Gluu would be happy to host this project on our github, http://github.com/gluufederation and donate QA resources to help test it with various U2F devices on the Gluu Server...
Speaking of a native implementation: in Comment 62, Richard Barnes pointed out that "the main thing that is lacking in Gecko at the moment is a USB HID API". I filed Bug 1198330 a while back to address the first part of adding a USB HID API to Gecko: incorporating a low-level USB HID library into the Firefox codebase. Once we have a low-level library that can speak the HID protocol directly to devices, we can create a high-level API (nsIHidService or what have you) that we can then expose to chrome script to implement U2F in the manner that Chrome did (via an extension).

I've submitted a patch to Bug 1198330 [0] that builds HIDAPI (the same HID library used by Yubico's libu2f-host) into mozilla-central. I'm not sure who to ask for a review, so if anybody on this bug thinks they can do it or know someone who can, go for it!

p.s. For some reason I can't add 1198330 as a dependency of this bug. If anybody else knows why I can't edit the "Depends on:" field, please let me know!

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1198330#c2
Depends on: 1198330

Comment 111

2 years ago
If you want me to connect you with the people who invented the FIDO code, please let me know who I should introduce. 4 months ago, they expressed interest in us enabling FIDO functionality in FFox and would likely assist, definitely answer questions to make this a reality.
Comment hidden (off-topic)

Comment 113

2 years ago
Please let me add something constructive (albeit tangential) to this derailed discussion ;-)

Many devices, notably phones, but also notebooks and desktops, have NFC sensors. U2F has can be used [over NFC](https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-nfc-protocol.html), and at least recent Yubikey NEOs support this standard.

It would be advantageous to design Firefox U2F support in layers, so that both "raw" USB HID and [pcsc](https://pcsclite.alioth.debian.org/) could be used. Pcsc Lite is apparently the most widely used cross-platform middleware for both NFC and serial smartcard access.

Comment 114

2 years ago
>Please let me add something constructive (albeit tangential) to this derailed discussion ;-)
>Many devices, notably phones, but also notebooks and desktops, have NFC sensors. 
>U2F has can be used [over NFC](https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-nfc-protocol.html), and at least recent Yubikey NEOs support this standard. 
> It would be advantageous to design Firefox U2F support in layers, so that
> both "raw" USB HID and [pcsc](https://pcsclite.alioth.debian.org/) could be
> used. Pcsc Lite is apparently the most widely used cross-platform middleware
> for both NFC and serial smartcard access


FIDO U2F over BLE or NFC supports are different subjects and these supports will be mostly used directly inside smartphone apps (and probably not even much inside smartphones browsers)... and even there, PCSC is out of scope, but I don't won't to discuss this here :) Note : Yubico do not yet support the new U2F over NFC specifications (noone officially does), they made their own tests and demonstrations with their RFID enabled models (dual NXP chip based) but on a day to day basis, these key owners are using USB. The first compatibility tests with the new BLE and NFC specifications are currently being done by few manufacturers, focusing on smartphone applications market.

On our side here, let's focus on asking for a simple standard FIDO U2F support inside Dekstop Firefox... A year passed without a real Mozilla reaction, let's stay simple and ask them to support existing FIDO U2F USB Security keys.
Comment hidden (advocacy)
Comment hidden (off-topic)
Comment hidden (off-topic)
(In reply to Matt H from comment #115)
> (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #97)
> > Please leave bug comments for technical discussion of this issue.  Bugzilla
> > is not the right place to debate what Mozilla should do.
> 
> This is the only place people can comment! So I expect more will. 

Mailing lists in fact are the place where Firefox priorities are discussed today.

> Mailing
> lists are inaccessible and invisible to most people. 

I understand what you are saying, but that does not change what communication channels are used by the Mozilla project today.  If you wish to affect the priority of this feature, I would recommend discussing it in the right place, which is firefox-dev mailing list and not this bug's comments.

> I found
> https://mail.mozilla.org/pipermail/firefox-dev/ but it's not obvious how to
> search it or reply to posts.

A searchable archive of the mailing list is available at https://groups.google.com/forum/#!forum/firefox-dev.  A believe you'll need to subscribe to the list itself at https://mail.mozilla.org/listinfo/firefox-dev before posting a message, though perhaps it is possible through the Google Groups interface (I've never tried).
firefox-dev isn't the best mailing list anyways as this support would be added to the platform. mozilla.dev.platform would be a better list: https://www.mozilla.org/en-US/about/forums/#dev-platform

Comment 120

2 years ago
(In reply to Matthew N. [:MattN] from comment #119)
> firefox-dev isn't the best mailing list anyways as this support would be
> added to the platform. mozilla.dev.platform would be a better list:
> https://www.mozilla.org/en-US/about/forums/#dev-platform

Here is a thread on that list where FIDO U2F is mentioned:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/u2f/mozilla.dev.platform/zdGJlDCiepU/Nce60hRlLQAJ

Comment 121

2 years ago
I have started a thread on mozilla.dev.platform about Fido U2F:

https://groups.google.com/forum/#!topic/mozilla.dev.platform/WR5E2Xd4Vdg

Please contribute to the discussion about the prioritizing this issue there, and do point out anything I may have omitted relevant to the issue at hand.
Comment hidden (me-too)
Comment hidden (me-too)
W3C is working on chartering a working group to develop standards for authentication; the draft charter is at https://w3c.github.io/websec/web-authentication-charter

Today the W3C announced that the FIDO specifications have been submitted to W3C as input to that work:
http://www.w3.org/Submission/2015/02/
http://www.w3.org/Submission/2015/02/Comment/

(Note that this also means the specifications are on a path to being developed under the W3C's patent policy.)
Release Note Request (optional, but appreciated)
[Why is this notable]:
The FIDO Alliance has been developing standards for hardware-based authentication of users by websites. Their work is getting significant traction, so the Mozilla Foundation has decided to join the FIDO Alliance. Work has begun in the W3C to create open standards using FIDO as a starting point. We are proposing to implement the FIDO U2F API in Firefox in its current form and then track the evolving W3C standard.

Background: The FIDO Alliance has been developing a standard for hardware-based user authentication known as “Universal Two-Factor” or U2F. This standard allows a website to verify that a user is in possession of a specific device by having the device sign a challenge with a private key that is held on the hardware device. The browser’s role is mainly (1) to route messages between the website and the token, and (2) to add the origin of the website to the message signed by the token (so that the signature is bound to the site).

Several major websites now support U2F for authentication, including Google, Dropbox, and Github. The W3C has begun the process of forming a “WebAuthentication” working group that will work on a standard for enhanced authentication using FIDO as a starting point.

[Suggested wording]: FIDO Universal Two-Factor API for hardware-based website authentication

[Links (documentation, blog post, etc)]:
https://fidoalliance.org/
https://fidoalliance.org/specifications/download/
http://w3c.github.io/websec/web-authentication-charter
relnote-firefox: --- → ?
Comment hidden (advocacy)
Depends on: 1231681
Comment hidden (me-too)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)

Comment 146

2 years ago
Can people please take this off-topic discussion elsewhere? You're spamming my mailbox with stuff that's in no way related to getting the U2F API implemented in Firefox.
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (advocacy)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (typo)
Comment hidden (off-topic)

Comment 167

2 years ago
FTR there's now an addon for U2F support https://addons.mozilla.org/en-GB/firefox/addon/u2f-support-add-on/, not my work and I make no claims about it's correctness.
Comment hidden (off-topic)
Comment hidden (advocacy)

Comment 170

2 years ago
I checked out this extension  https://addons.mozilla.org/en-GB/firefox/addon/u2f-support-add-on/, with authorizing on https://github.com/ - works great. Now, if Google has made support for ...
Comment hidden (obsolete)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (off-topic)
Comment hidden (obsolete)
Comment hidden (off-topic)
Comment hidden (off-topic)

Updated

2 years ago
Depends on: 1244959

Updated

2 years ago
Depends on: 1245527
Comment hidden (off-topic)
Comment hidden (advocacy)

Updated

a year ago
Depends on: 1265472
Depends on: 1267247
Blocks: 1273644
Comment hidden (advocacy)
Whiteboard: [parity-chrome] → [parity-chrome] [extension available: https://addons.mozilla.org/firefox/addon/u2f-support-add-on/ ]
Comment hidden (off-topic)
Comment hidden (advocacy)
Comment hidden (advocacy)