1065729 - [meta] Implement the FIDO Alliance u2f javascript API

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, enhancement, P3)

Description

[Axel Nennker]

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

Comment 1

[Axel Nennker]

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

Comment 2

[Paul [:pmac] McLanahan]

Google announced Chrome support this morning:

http://googleonlinesecurity.blogspot.com/2014/10/strengthening-2-step-verification-with.html

Comment 3

[Axel Nennker]

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.

Comment 4

[Axel Nennker]

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.

Comment 5

[Harlan Lieberman-Berg]

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.

Comment 6

[Axel Nennker]

Attachment: 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

[Paul Holder]

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/

Comment 8

[Benjamin Kerensa [:bkerensa]]

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 9

[Urda]

Firefox really needs to be getting on board with this, especially if Chrome has support for it already.

Comment 10

[Simon Josefsson]

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.

Comment 11

[Axel Nennker]

(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

Comment 12

[Axel Nennker]

Attachment: 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.

Comment 13

[Simon Josefsson]

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

[Simon Josefsson]

> 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

[Timothy Hamlett]

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

/Timothy

Comment 16

[Nibbles Dev Team]

Just got a U2F device, works great with chrome, please support it in FF!

Comment 17

[Axel Nennker]

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 18

[1tlister]

I have a new U2F device I can test with. Let me know when a beta is ready - please.

Comment 19

[1tlister]

I have a new U2F device I can test with. Let me know when a beta is ready - please.  

I think this is a worth while effort for Mozilla and associated banking, merchants, ID providers and E-mail providers to work on.

Comment 20

[Stavros Korokithakis]

I can also help test this.

Comment 21

[[e-mail]]

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 22

[[e-mail]]

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 23

[Urda]

I am willing to invest and test in this when a beta is available.

Comment 24

[Kashif Shah]

I have a couple of Yubico Yubikey's that I can use for testing u2f in Firefox as well.

Comment 25

[Axel Nennker]

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

Comment 26

[Axel Nennker]

Attachment: 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.

Comment 27

[Simon Josefsson]

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

Comment 28

[Arnar]

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.

Comment 29

[Benjamin Kerensa [:bkerensa]]

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

[Timothy Hamlett]

(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?

Comment 31

[Benjamin Kerensa [:bkerensa]]

(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

[Mike Nicholls]

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.

Comment 33

[Axel Nennker]

(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

[dattaz]

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 35

[Daniel Holbert [:dholbert]]

[clearing testsuite flags set by 1tlister in comment 18 -- please don't play with bug flags if you don't know what they mean. These particular ones are only meaningful after a bug has been fixed.]

Comment 36

[dennis]

Hey guys,

I've bought an U2F key a few weeks ago. The Plug-up Security Key (http://sk.plug-up.com/). This keyless stick is a lot cheaper that that one from Yubico. 

I had contact to LastPass regarding supporting this as they are a member of the FIDO alliance. They are just waiting for Firefox to support U2F so they can rollout this feature to the world. On Chrome it would already works.

Whats the state for U2F on Firefox? Can anyone give an ETA?

Thank you very much,
Dennis

Comment 37

[mikejonesey]

I'm very keen to see some action on this,

have read the u2f js documentation (will need to read a couple more times), but never made a mod on ff, will read the google docs tonight. If anyone has any tips on what i should invest time in to help, it would be much appreciated.

Kind Regards,
Mike

Comment 38

[HLFH]

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

[riccardo]

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

Comment 40

[Dmitri Smirnov]

(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 41

[Axel Nennker]

#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

[HLFH]

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

[Mike Robinson]

(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

[V. Korn]

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

[Anders Rundgren]

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

Comment 46

[u541675]

(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 47

[V. Korn]

(In reply to Anders Rundgren from comment #45)
> I think FIDO support in Firefox OS would be more interesting than a desktop
> implementation.

As mature user i highly anticipating ability to use U2F device to protect my Google and hosting provider account. Rejecting desktop Firefox in favor to Firefox OS will be just another reason to switch to Chromium.

Comment 48

[Anders Rundgren]

Maybe rejecting the desktop was too strong.
However, ignoring Firefox OS would be a mistake IMO.
Targeting Firefox OS will also bring in the long overdue renovation of the Firefox OS crypto platform.

Comment 49

[Brad Hill]

+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

[V. Korn]

(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 51

[dennis]

Please get it finally going! For what are you waiting? Just do it.

When U2F 2.0 is ready in one, two or maybe three years you can still upgrade. But until then we have additional security for our web applications. Applications that most of us use - every day.

Comment 52

[Devdatta Akhawe [:devd]]

+1. I agree with Brad that this will push a bunch of companies over the fence re U2F support.

Comment 53

[Luke Faraone]

(In reply to Devdatta Akhawe [:devd] from comment #52)
> +1. I agree with Brad that this will push a bunch of companies over the
> fence re U2F support.

Agreed, and will also increase the value prop for users, thus making it more likely they adopt it.

Comment 54

[Lukas]

Google just announced, that Google Apps will use this. http://googleappsupdates.blogspot.com/2015/06/a-special-offer-and-new-controls-for.html

Comment 55

[Corey Richardson (:cmr)]

It'd be great to finally have crytographically strong authentication in a freedom respecting browser.

Comment 56

[jolamb]

I signed up just for this bug. I would love to see FIDO 1.0 support in Firefox sooner than later, and will be happy to help test. I have a couple of Yubikey EDGE devices I can use.

Comment 57

[Tony Arcieri]

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

[riccardo]

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

[Gerhard Poul]

(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.

Comment 60

[Nick Alexander :nalexander [he/him]]

(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

Comment 61

[mike]

Hi guys. Gluu would really love to see this plugin also: http://gluu.org

I wish we had a resource to allocate to make it happen! But the Gluu Server is a FOSS OpenID Provider that also provides FIDO U2F server endpoints. Its really easy to deploy ('apt-get install gluu-server'), and we'd be happy to answer any questions. The Gluu Server also ships with U2F, all you have to do is click a button to enable it. I recorded this video: http://gluu.co/fido-u2f to show how to configure and test it.

Thanks a lot for all the hard work making Firefox happen!

Comment 62

[Richard Barnes [:rbarnes]]

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.

Comment 63

[Nick Alexander :nalexander [he/him]]

(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

[Jeffrey Walton]

(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

[semenko]

(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

[Brad Hill]

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

[Tony Arcieri]

(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 68

[Jeffrey Walton]

(In reply to Tony Arcieri from comment #67)
> (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.

OK, this kind of thinking got us into this trouble in the first place.

Passwords by themselves are not evil. But the chronic mishandling of them got us into a bad spot. Password handling meant the user and the site needed to do everything correctly (for some definition of 'correct'). But many users and many sites did not do things correctly.

Asking users and sites to layer additional security on-top seems like its just repeating history. If they were going to do things correctly, then they probably would have done it by now.

> U2F definitely doesn't solve everything out of the gate, but I think it's
> disingenuous to suggest it has to.

Well, I think its important to understand the security goals, but its not clear we have them.

If the U2F was meant to increase the security of the data, then it did not meet expectations under many conditions. All it did was shorten the time window an adversary could impersonate the authorized user in some instances. But the adversary who gets who owns the channel still has access to the long-lived cookie (i.e., the claim that interception is a valid use case). In this case, the data is still at risk even though there are stronger assurances on the user's identity.

But to be clear, I'm not saying it useless or worthless. I'm just saying there are some architectural shortcomings or gaps that were not addressed. (Personally, I'd like to see it incorporated in both IE and FF).

Comment 69

[Tony Arcieri]

(In reply to Jeffrey Walton from comment #68)
> OK, this kind of thinking got us into this trouble in the first place.

Actually, the current mess we're in is the limitations of password based authentication.

> Asking users and sites to layer additional security on-top seems like its
> just repeating history.

Are you decrying the entire concept of 2FA?

> If the U2F was meant to increase the security of the data, then it did not
> meet expectations under many conditions. All it did was shorten the time
> window an adversary could impersonate the authorized user in some instances.
> But the adversary who gets who owns the channel still has access to the
> long-lived cookie (i.e., the claim that interception is a valid use case).
> In this case, the data is still at risk even though there are stronger
> assurances on the user's identity.

You're conflating AuthN with bearer credential security. U2F *can* be used to bolster the latter. If you really care about the security of bearer credentials, why don't I see you participating in the Tokbind WG? I can't say I agree with everything they're doing (in fact I've been a vocal critic of many of their suggestions) but that's the right place to solve the problem you're bringing up, not FIDO.

> I'm just saying there are some architectural shortcomings or gaps that were not addressed.

U2F is well-positioned to augment origin-bound bearer credential. The fact it doesn't do so out of the gate isn't an "architectural shortcoming", and I would consider insisting it does a layering violation.

In general, it seems like you're actively fighting against having nice things. If you really want them, perhaps you should participate in the relevant IETF WGs instead of whining about it on this ticket?

Comment 70

[Jeffrey Walton]

(In reply to Tony Arcieri from comment #69)
> (In reply to Jeffrey Walton from comment #68)
> > OK, this kind of thinking got us into this trouble in the first place.
> 
> Actually, the current mess we're in is the limitations of password based
> authentication.
> 
> > Asking users and sites to layer additional security on-top seems like its
> > just repeating history.
> 
> Are you decrying the entire concept of 2FA?

No, not at all. I'm just pointing out that incomplete remediations can be problematic.

But I can't take credit for it. Saltzer and Schroeder posited it in 1975 with "The Protection of Information in Computer Systems", https://www.acsac.org/secshelf/papers/protection_information.pdf.
 
> > I'm just saying there are some architectural shortcomings or gaps that were not addressed.
> ...
> 
> In general, it seems like you're actively fighting against having nice
> things. If you really want them, perhaps you should participate in the
> relevant IETF WGs instead of whining about it on this ticket?

I'm kinda trying to stay out of the debate. Richard Barnes provided some counter-arguments, but he did not point out some of the current short comings. Since the pros/cons lacked some perspective, I added it. I'd hardly call that whining about it.

Like I said, I'd like to see IE and FF adopt it. And then I'd like to see all sites use it for all transactions, and not just initial log-in.

(And I'd like to see it work in places other than my desktop, like on my phones and tablets. I'm interested in seeing how the lack of USB or the lack of USB OTG will be handled).

Comment 71

[mike]

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 72

[Tom Geompse]

Please don't debate/troll/spam here.

Topic ITT : implementing FIDO U2F in Firefox
Suggestion : do as Google, enable extensions to use an USB API

Irrelevant : is 2FA a good thing ?
Irrelevant : is FIDO evil ?
Irrelevant : is Firefox nice ?

Comment 73

[Zach Lym]

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

[carl.hoerberg]

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

Comment 75

[Axel Nennker]

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

[Clint]

Github added support for U2F today:

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

Comment 77

[mark]

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

Comment 78

[Daner]

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 79

[roidelapluie]

(In reply to Daner from comment #78)
> 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 ;-)

Obviously Firefox developers did not wait for you, neither did Yubico. If you would have read this thread you would have figured out that sooner this year Firefox testers and developers got 200 Yubikeys to develop this feature.

Comment 80

[malu_pigi]

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?

Comment 81

[Nick Alexander :nalexander [he/him]]

(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!

Comment 82

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 83

[Stefan Neufeind]

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 ... :-)

Comment 84

[Martin Giger [:freaktechnik]]

(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 85

[matt]

Please add FIDO/U2F supported in Firefox

Comment 86

[matt]

Please add FIDO/U2F supported in Firefox

Comment 87

[malu_pigi]

(In reply to Bill McCloskey (:billm) from comment #82)
> 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.

Well not prioritizing support for U2F is a big miss for a product like Firefox! 
Google, Dropbox, Github and some others are already offering U2F as an extra security measure. LastPass is even waiting for you guys to implement U2F support in Firefox, before implementing it in LastPass! (https://lastpass.com/support.php?cmd=showfaq&id=8126). So by not caring much about U2F support, you are actually holding up new security standards (FIDO Universal 2nd Factor) from being deployed by other companies (because Firefox users cannot make use of the U2F advantages right now).

A product like Firefox, which is ought to be excellent in privacy and security, should support new open security standards! And you should definitely prioritize U2F support since the first version of this standard has been released more than a year ago, is being implemented by several software/service providers, and still no Firefox users can make advantage of this!!

Comment 88

[asq]

i've stopped using Firefox and switched to Chrome exclusively for a purpose to use u2f. now i'm really disappointed that you guys are holding this feature from adoption by service and content providers. Lastpass is one that mentions this, i guess there are many more that postponed it due to insufficient adoption by browsers (currently Chrome only).

Comment 89

[dennis]

I think they give a **** about U2F and people asking for it.

For me this means: 
Chapter closed!


Have a nice day guys!

(In reply to malu_pigi from comment #87)
> (In reply to Bill McCloskey (:billm) from comment #82)
> > 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.
> 
> Well not prioritizing support for U2F is a big miss for a product like
> Firefox! 
> Google, Dropbox, Github and some others are already offering U2F as an extra
> security measure. LastPass is even waiting for you guys to implement U2F
> support in Firefox, before implementing it in LastPass!
> (https://lastpass.com/support.php?cmd=showfaq&id=8126). So by not caring
> much about U2F support, you are actually holding up new security standards
> (FIDO Universal 2nd Factor) from being deployed by other companies (because
> Firefox users cannot make use of the U2F advantages right now).
> 
> A product like Firefox, which is ought to be excellent in privacy and
> security, should support new open security standards! And you should
> definitely prioritize U2F support since the first version of this standard
> has been released more than a year ago, is being implemented by several
> software/service providers, and still no Firefox users can make advantage of
> this!!

Comment 90

[Charlie]

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 91

[bpeters.284]

I've been waiting for nearly a year now.  I don't think Mozilla is going to devote any resources to this anytime soon.  You can join me in disillusioned land where we keep seeing jibba jabba and no positive motion on this issue.

Comment 92

[Tom Geompse]

Unfortunately it is Mozilla's way of doing things today. Whenever something new and powerfull is created, Firefox's users cannot have it.
I've been waiting for the ability to paste a screenshot (Prnt.Scr. then CTRL+V) for yearS, which we use every day in Google Chrome.
FIDO support is requested for more than a year now, and will not be available until years too, if ever.
My first bugzilla "minor bug" report is about to be 14 years old (bug 126309) !

Today, we simply tell our 60'000+ users to use Google Chrome instead of the obsolete browser named "Firefox". Sad story. True story.

Comment 93

[richi]

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 94

[Jeffrey Walton]

(In reply to richi from comment #93)
> 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.

OK, I bite... Mozilla literally makes hundreds of millions annually. They almost lost their tax except status because they were making so much money with their arrangement with Google. Confer, http://en.wikipedia.org/wiki/Mozilla_Foundation#Financing.

I think bug bounties and feature bounties are a good idea, and I think its a good idea to give back. But I think its misplaced in this instance with Mozilla. I can't help but wonder why Mozilla is not spending their own money or a few developers or contractors.

Comment 95

[Jeroen Hoek]

Good constructive idea Richi. Worth a try.

The design of FIDO U2F is sound, and the world needs a decent open, safe, and user-friendly 2FA solution, but it will only gain traction if there is browser support. Especially from an independent open browser.

I would love to know why Mozilla is not able to allocate developer resources to this bug, and I agree with Jeffrey that it should not be necessary to raise a bounty for this. On the other hand, I would rather not be forced to use Chrome for something that should work in every modern browser.

Comment 96

[Michael Kliewe]

My Chrome-friends are also making fun of me that Firefox does not support this nice security feature. Some people even switched their browser because of this single feature.

If Mozilla does not want to loose even more users (especially the techies who are security-sensitive), they should take some money and implement this... The community wants to help I guess, but some basic things have to be done by Mozilla to start this.

Comment 97

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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 98

[Charlie]

Richi, thank you for the bountysource idea. I just posted a $100 bounty on this issue, good for six months. I think this one is worth it. I hope others who are advocating for this will consider that. Thank you in advance to whoever helps push it over the finish line :)

Comment 99

[Charlie]

Wow, in the last couple days the bounty on this issue jumped to $850! Thanks everyone!
https://www.bountysource.com/issues/10401143-implement-the-fido-alliance-u2f-javascript-api/backers

Comment 100

[Pawel Chmielowski]

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 101

[soumagne.alexis]

@Pawel Chmielowski 
I've tested with success your plug-in in version 0.0.2 with the URL http://demo.yubico.com/u2f. It was done with Firefox 41.0.2 on Windows 10.

Comment 102

[mozilla]

The extension works with Firefox ESR 38.3.0 on Windows 7.

Comment 103

[Martin 'Nexus' Mlynář]

Works fine with 41.0.2, Arch Linux, 64bit

Comment 104

[u540843]

Extension works great on Fx 42.0b8 on Windows 8.1 too :)

Comment 105

[Frédéric MARTIN]

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 106

[V. Korn]

Extension totally not works with U2f token from HyperSecu (hyperfido.com) on Linux and i dont see reason of "Open Standard" in which only some vendors devices supported.

Comment 107

[mikejonesey]

@Pawel many thanks,

Linux, firefox 41.0.2, Yubikey neo tested

Comment 108

[Garrett Robinson [:grobinson]]

Please take further discussion of the extension elsewhere, this bug is for discussing a native implementation in Firefox.

Comment 109

[mike]

@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...

Comment 110

[Garrett Robinson [:grobinson]]

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

Comment 111

[Jason Bradford]

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 112

[Ben Toews]

The Firefox add-on works on GitHub now.

Comment 113

[Eugene Crosser]

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

[Frédéric MARTIN]

>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 115

[Matt H]

(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 are inaccessible and invisible to most people. I found https://mail.mozilla.org/pipermail/firefox-dev/ but it's not obvious how to search it or reply to posts.

Anyway, all the best with this feature. I've added my vote above.

Comment 116

[Arnar]

(In reply to Jason Bradford from comment #111)
> 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.

We're lurking here too. See comment #28 for links that may be helpful, and we are definitely happy to answer questions and help out.

Comment 117

[ein.hacker]

(In reply to Matt H from comment #115)

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

U2F seems to be no topic among firefox developers. Trying https://www.google.com/?gws_rd=ssl#q=site%3Amail.mozilla.org%2Fpipermail%2Ffirefox-dev+U2F yields no match.

Comment 118

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(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).

Comment 119

[Matthew N. [:MattN]]

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

[Charlie]

(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

[Jeroen Hoek]

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 122

[Stephen Pollei]

I just bought a yubikey neo that should arrive within a week; do you still need testers of nightly or developer edition?

Comment 123

[Andrei Petcu]

I also just got a YubiKey and I hang out mostly in Nightly Firefox so I can test also :)

Comment 124

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.)

Comment 125

[Lawrence Mandel [:lmandel] (use needinfo)]

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

Comment 126

[Pierre Radermecker]

I guess when an legitimate issue is that long, it is not a good sign. Using Chrome is the only alternative which is such a shame because I just love Firefox better ;-(

Comment 127

[mike]

I hear through the grapevine that "Mozilla is working on native Firefox support for U2F with help from Yubico, GitHub and Freedom of the Press. Expects to be ready in about 3 months."

Comment 128

[Anders Rundgren]

I doubt that discrete U2F tokens will ever become mainstream.
The future for tokens is HW-virtualization which is available in any modern CPU.

A soft key version of U2F for Firefox would actually be quite interesting, particularly since Mozilla are following the Google dogma saying that "keygen" is harmful and must be removed.

Comment 129

[Daner]

HW virtualization does not solve the problem to have a different token not on the same device.
I can bring the token with myself, but I don't bring my desktop PC when I go around.

Comment 130

[Tom Geompse]

Maybe Anders wants to authenticate the device and no the user

Comment 131

[Anders Rundgren]

You need a copy of a token?
No problem, you log in using your registered token and then ask for a on-time-sign-up code which you use for securely enrolling the new token (in another device).

But more likely is that you have ALL your tokens in a mobile phone and use the phone also when logging on through a PC.  This is established on a huge scale in Sweden (Mobile BankID).

Mobile BankID essentially works as my QR-ID demo (although relying on hard-coded URLs):
https://mobilepki.org/webauth/home
https://cyberphone.github.io/openkeystore/resources/docs/QR-ID-presentation.pdf

Comment 132

[Frédéric MARTIN]

Hi Anders, nice to see you again here, I know you from many other great projects and comments but... please stop promoting non-sens QR Code based solutions. Without a strong link between desktop and smart phone, it is a security nightmare to use a smart phone to control a Desktop access.

Reminder: All-in-one four slides presentation against SMS / OTP / TOTP / QR CODE as secure solutions (no, they are not):

http://www.neowave.fr/pleaseno/SMS_OTP_TOTP_QRCODE_SSL_ARE_NOT_SOLUTIONS.pdf

And about TEE / HW virtualisation / TrustZone base solutions... oh boy... please make one that I can use/deploy right now on my smart phones and right now use/deploy on my server... and we'll talk about that after...

FIDO U2F nearly checks every points I know we both care about: 
[x] Standard Cryptography (ECC P256)
[x] PKI 
[x] Simplicity (to use and to implement)
[x] Open Standard 
[x] Lots of open source libraries/servers/applications are available
[x] Independent Secure Elements (freedom of choice/implementation)
[x] Not expensive
[x] It works. right now.

So please join to the move :)

Comment 133

[mike]

Anders is wrong about U2F not becoming mainstream. Do an Amazon search for U2F: http://gluu.co/u2f-thentication  Note: there are currently three vendors, with tokens as low s $6/unit--retail! That's not too much more expensive than your house key. U2F tokens is already a competitive market! And Nitrokey is developing an open hardware U2F token: http://gluu.co/indiegogo-nitrokey

The reason U2F will actually work is economics. The main impediment to 2FA has been deployment expense at the website. Let's face it--passwords are free for websites to support. And so is U2F--because the expense is moved to the user.

If U2F was only supported by one website, or only had one vendor, it would be dead on arrival, just as Anders suggests. However, with many websites supporting it--this type of hardware token with no battery and a cheap U2F interface will achieve production economies of scale to drive down the price. 

No one type of authentication is enough. Without many types of authentication, you can't automatically handle credential reset. But there is no question that U2F is one of the most important tools we currently have in our tool chest. 

For more information, I'm giving a talk at RSA Conference this year called "From Meat to Electrons and Back Again." Its a survey of authentication technology. Hopefully RSA will put the video online too for those who can't make it to SF or can't get your company to buy you a conference pass.

Comment 134

[Anders Rundgren]

Hi Frédéric,

I'm fully aware of the problem you mention
https://github.com/w3c/websec/issues/17
but the folks running W3C prefer not acknowledging those including giants like Intel.

OTOH, the U2F people greatly "oversell" their stuff as well, particularly when it comes to the practicality of having a unique key for every site.  This will in reality create a huge advantage for providers like Google, Facebook, PayPal and Alibaba.

We will see what happens :-)

Comment 135

[Frédéric MARTIN]

"OTOH, the U2F people greatly "oversell" their stuff as well, particularly when it comes to the practicality of having a unique key for every site.  This will in reality create a huge advantage for providers like Google, Facebook, PayPal and Alibaba"

Can you elaborate? I did not understand this part

Comment 136

[Andrei Petcu]

Google and Facebook will have different key pairs on the U2F device. It is part of the register U2F token step. Different providers will not be able to check if the device has been used for another site. Is this what you mean, Anders?

Comment 137

[Frédéric MARTIN]

> And Nitrokey is developing an open hardware U2F token:
> http://gluu.co/indiegogo-nitrokey

While I enjoy this project (I am already a backer :) ), Nitrokey has -for now- nothing to do with an open source FIDO U2F solution. It is mostly about open hardware storage encryption (and openPGP).

Nitrokey guys are reselling/rebranding closed source low-cost FIDO U2F USB tokens from PlugUp/Happlink (another small french company...) and use them as rewards/perks too. Nitrokey is not focusing on FIDO U2F open source solution, for now.

But anyway, the french dev team behind these lowcost FIDO U2F tokens are working on open source FIDO U2F solutions on their side (outside plugup/happlink). FYI, they recently release the first open source Java Card applet compatible with the soon-to-be released/finalized FIDO U2F over NFC specifications.

https://github.com/LedgerHQ/ledger-u2f-javacard

More info on GitHub page but here is a quick overview:

Ledger U2F Java Card Applet
---------------------------------------
This applet is a Java Card implementation of the FIDO Alliance U2F standard
It uses no proprietary vendor API and is freely available on Ledger Unplugged
(Note: Ledger Unplugged is a NXP JCOP based contactless smart card with 
another Java Card applet for Bitcoin) and for a small fee on other Fidesmo 
devices (Note: Generic Fidesmo cards are the same NXP JCOP based 
contactless smart cards that you can buy with or without applets => you can 
load applets from their online services after initial purchase).

> [...] there is no question that U2F is one of the most important tools 
> we currently have in our tool chest. 

Yes it is. And this is not even forbidden to think about forked/enhanced solutions on this base :)

Comment 138

[Joseph P. Hillenburg]

Did we all forget that FIDO is about far more than just $6 USB tokens? And users should still be allowed to use it if they want -- it's superior to most of the alternatives.

Comment 139

[mike]

I'd like to point out that I'm not with affiliated with the U2F standard process, and Gluu is not a member of FIDO, although the Gluu Server does have U2F endpoints built-in now. Will there be further versions of a non-battery based token in the future--surely. But U2F is a pretty close starting point, its easy to implement, and when something better comes along, we'll support that too. Gluu is a tiny little company. If we could find the budget to do this, surely a huge community backed by some really deep pockets could do it too.

Comment 140

[mike]

I'd like to point out that I'm not with affiliated with the U2F standard process, and Gluu is not a member of FIDO, although the Gluu Server does have U2F endpoints built-in now. Will there be further versions of a non-battery based token in the future--surely. But U2F is a pretty close starting point, its easy to implement, and when something better comes along, we'll support that too. Gluu is a tiny little company. If we could find the budget to do this, surely a huge community backed by some really deep pockets could do it too.

Comment 141

[Anders Rundgren]

An issue list is probably not a suitable place for debates but let me finish my part of this with some thoughts on why I believe "phone tokens" are here to stay, with and without U2F.

- Secure and convenient web-payments have failed.  Practically all new payment systems are "App" based.

- The browser-vendors deprecated plugins forcing the eID-market to create new solutions.  Quite a bunch have taken similar ways as Mobile BankID.

- Phone tokens have [almost] no processing and storage limitations making this path very extensible.

- The mobile phone have become the thing you rather never leave the home without.

- HW-virtualization has to date been severely hampered by business- and IPR-considerations.  U2F will finally open this door since U2F is free from such problems.

Comment 142

[terje]

Yes, phone tokens are probably here to stay, no matter if you like it or not. 
I fail to see how that relates to implementing FIDO U2F in a browser (what this ticket is about). 
Part of the very point of U2F (or it's common implementations) is to have a dedicated token, which a smartphone clearly is not.

Comment 143

[Anders Rundgren]

(In reply to terje from comment #142)
> I fail to see how that relates to implementing FIDO U2F in a browser (what
> this ticket is about).
Before Mozilla shelved FFOS, a "soft" implementation would have been a useful way of adding U2F to this platform.  IMO a "soft" solution could be quite useful even in a PC.  If not, then the whole WebCrypto thing was also wrong.

> Part of the very point of U2F (or it's common implementations) is to have a
> dedicated token, which a smartphone clearly is not.
As I understood it, the purpose of U2F was (and is) replacing passwords.

Comment 144

[mashkin]

(In reply to Anders Rundgren from comment #143)
> Before Mozilla shelved FFOS, a "soft" implementation would have been a
> useful way of adding U2F to this platform.  IMO a "soft" solution could be
> quite useful even in a PC.  If not, then the whole WebCrypto thing was also
> wrong.
> ...
> As I understood it, the purpose of U2F was (and is) replacing passwords.
Then you misunderstood the concept.
"U2F" stands for "Universal *Second* Factor" (in addition to the primary authentication mechanism like a password). The concept aims to integrate a secure hardware token (which a "soft" implementation is clearly not).

You should read up on FIDO's specifications (https://fidoalliance.org/specifications/overview/).
Therefore I fail to see any relation to

Comment 145

[Jeffrey Walton]

(In reply to mashkin from comment #144)
> (In reply to Anders Rundgren from comment #143)
> > ...
> > As I understood it, the purpose of U2F was (and is) replacing passwords.
> Then you misunderstood the concept.
> "U2F" stands for "Universal *Second* Factor" (in addition to the primary
> authentication mechanism like a password). The concept aims to integrate a
> secure hardware token (which a "soft" implementation is clearly not).

You have to be careful here... ARM Trust Zones can create the necessary separation at the hardware level. See, for example, "Securing the Future of Authentication with ARM TrustZone-based Trusted Execution Environment and Fast Identity Online (FIDO)", http://www.arm.com/files/pdf/TrustZone-and-FIDO-white-paper.pdf.

The "necessary separation" simply means the segregation or isolation required to keep them independent.

Jeff

Comment 146

[Thom Wiggers]

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 147

[Anders Rundgren]

(In reply to Thom Wiggers from comment #146)
> 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.
What I have tried to show which is also proven by the ARM paper is that there are alternatives to the existing implementation plan.

Even a lame "soft" implementation may actually strengthen the uptake of U2F, albeit at the (probable) expense of HW-token sales.  Using operating systems that support application-specific data-space like Android, soft solutions are adequ

Comment 148

[Thom Wiggers]

(In reply to Anders Rundgren from comment #147)
> (In reply to Thom Wiggers from comment #146)
> > 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.
> What I have tried to show which is also proven by the ARM paper is that
> there are alternatives to the existing implementation plan.
> 
> Even a lame "soft" implementation may actually strengthen the uptake of U2F,
> albeit at the (probable) expense of HW-token sales.  Using operating systems
> that support application-specific data-space like Android, soft solutions
> are adequ

You're arguing that a software-side U2F token be implemented. That is completely unrelated to this feature request. Please take this discussion elsewhere.

Comment 149

[Anders Rundgren]

(In reply to Thom Wiggers from comment #148)
> You're arguing that a software-side U2F token be implemented. That is
> completely unrelated to this feature request. Please take this discussion
> elsewhere.
Then I must assume that this issue also is completely unrelated to:
https://www.mozilla.org/en-US/firefox/android/

Comment 150

[m.bachmann]

My 2 cents re: adoption: Our company has just recently moved to FIDO U2F auth keys. Since that move, Firefox cannot be used anymore as main browser. Pity, but who lags looses. I'd love if the foundation would get their act together and fix this long-standing issue.

Comment 151

[Jason Bradford]

(In reply to Anders Rundgren from comment #143)
> (In reply to terje from comment #142)
> > I fail to see how that relates to implementing FIDO U2F in a browser (what
> > this ticket is about).
> Before Mozilla shelved FFOS, a "soft" implementation would have been a
> useful way of adding U2F to this platform.  IMO a "soft" solution could be
> quite useful even in a PC.  If not, then the whole WebCrypto thing was also
> wrong.
> 
> > Part of the very point of U2F (or it's common implementations) is to have a
> > dedicated token, which a smartphone clearly is not.
> As I understood it, the purpose of U2F was (and is) replacing passwords.

U2F is for second factor authenticators (not restricted to tokens). UAF (Universal Authentication Framework) is the password-replacement protocol. The browser support is necessary if you want to use FFox to go to a FIDO-enabled RP site and interact with it in a FIDO way regardless of if you're talking USB tokens or Mobile devices (Like docomo smartphones or any other FIDO client technology).

Comment 152

[Anders Rundgren]

(In reply to Jason Bradford from comment #151)
> > As I understood it, the purpose of U2F was (and is) replacing passwords.
> 
> U2F is for second factor authenticators (not restricted to tokens).
Well, U2F is the result of a 5-year project originated by Google for killing passwords.

Naturally Mozilla should implement support for U2F, I'm just questioning that following in the steps of Google (which seems to be the de-facto situation for Microsoft as well), automatically will lead to universal acceptance.

As an example Google have failed completely with mobile payments and are doing an abysmal job with browser extensions (https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html).

AFAICT, the mobile phone already *is* the token of choice and there's nothing we can do about that.  The [unilateral] decision by the browser vendors to deprecate plugins have contributed to this [for the Web somewhat sad] development.

Leaving this thread to the implementers.  Feel free emailing me privately!

Comment 153

[mike]

Saying "U2F is the result of a 5-year project originated by Google for killing passwords" is 
factually inaccurate. Yubico played a major role in the devleopment of U2F. There are several
other vendors also providing U2F keys: Nitrokey (an open hardware token), Plug-up international,
and Hyperfido. And many SaaS providers are supporting U2F besides Google--like dropbox and github,
just to name two--not to mention open source IAM platforms like the Gluu Server. 

No one is suggesting that Firefox follow Google Chrome blindly. There are a plethora of good reasons 
to implement U2F support, as documented above.

Comment 154

[Tony Arcieri]

For clarity, the FIDO Alliance consists of:

- Alibaba Group
- American Express
- ARM
- Bank of America
- CrucialTec
- Daon
- Discover
- Egis
- Google
- Infineon
- ING
- Intel
- Lenovo
- MasterCard
- Microsoft
- Nok Nok Labs
- NTT Docomo
- NXP
- Oberthur Technologies
- PayPal
- Qualcomm
- RSA
- Samsung
- Synaptics
- USAA
- Vasco
- VISA
- Yubico

Much of the initial work came via AuthenTec, who was acquired by Apple (for Touch ID). A great deal of subsequent work was by PayPal employees Jeff Hodges and (former employee) Brad Hill.

Google is notable because they shipped U2F in Chrome and Google Accounts, and because they use U2F internally.

They gave U2F critical mass, but U2F is in no way a "Google standard" and it cannot be judged by Google alone.

As several people have repeatedly noted in this thread, U2F is *not restricted to tokens*. A software implementation of U2F is available in every copy of Windows 10 as part of the "Passport 2.0" (formerly Next Generation Credentials) authentication system.

Comment 155

[javucho1000]

True. It wasn't originated at Google.
https://fidoalliance.org/about/history



>>For clarity, the FIDO Alliance consists of:
And many others including but not limited to:
International Systems Research (isr)
Mozilla

https://fidoalliance.org/membership/members/

Comment 156

[Frédéric MARTIN]

(In reply to Tony Arcieri from comment #154)

Thanx for your post. BTW, two small mistakes:

> For clarity, the FIDO Alliance consists of:
> 
> - Alibaba Group
[...]
> - Yubico

For even more clarity, FIDO Alliance is larger than this.
This was "only" the "board" members list.
Complete list: https://fidoalliance.org/membership/members/

> A software implementation of U2F is available in every copy of 
> Windows 10 as part of the "Passport 2.0" (formerly Next
> Generation Credentials) authentication system.

This is simply not true. This cake is a lie. :)

I know there was a announcement from Microsoft to support FIDO 2.0 in 
the future but FIDO 2.0 is / will be very different from FIDO "1.0" U2F 
and until today, there is still nothing related to FIDO 2.0 in Windows 10. 
This was just an announced commitment. We can only say that parts of
Windows 10 authentication architecture "reflects Microsoft inputs into 
the FIDO 2.0 Specification Technical Working Group". That's all.

---

Anyway, Mozilla foundation was supposed to join the FIDO Alliance very soon,
any news on this ?

Comment 157

[Jason Bradford]

(In reply to Anders Rundgren from comment #152)
> (In reply to Jason Bradford from comment #151)
> > > As I understood it, the purpose of U2F was (and is) replacing passwords.
> > 
> > U2F is for second factor authenticators (not restricted to tokens).
> Well, U2F is the result of a 5-year project originated by Google for killing
> passwords.

U2F is what happened when that Google gnubby project you are indicating intersected with Google's interest in the FIDO Alliance and participation in the spec design when they realized that it was in their interest.

Comment 158

[Tony Arcieri]

(In reply to Frédéric MARTIN from comment #156)
> > A software implementation of U2F is available in every copy of 
> > Windows 10 as part of the "Passport 2.0" (formerly Next
> > Generation Credentials) authentication system.
> 
> This is simply not true. This cake is a lie. :)
> 
> I know there was a announcement from Microsoft to support FIDO

Microsoft *claims* "Passport 2.0" supports FIDO:

https://technet.microsoft.com/en-us/library/dn985839(v=vs.85).aspx

So, either you're wrong, or they're lying. I'm not a Microsoft fan and do not have any Windows 10 devices with which I can confirm or deny your claims or theirs. But you're alleging they suggested they'd support it and backpedaled. That's not the case:

"Microsoft Passport lets users authenticate to a Microsoft account, an Active Directory account, a Microsoft Azure Active Directory (AD) account, or non-Microsoft service that supports Fast ID Online (FIDO) authentication."

Comment 159

[Frédéric MARTIN]

(In reply to Tony Arcieri from comment #158)
> (In reply to Frédéric MARTIN from comment #156)
> > > A software implementation of U2F is available in every copy of 
> > > Windows 10 as part of the "Passport 2.0" (formerly Next
> > > Generation Credentials) authentication system.
> > 
> > This is simply not true. This cake is a lie. :)
> > 
> > I know there was a announcement from Microsoft to support FIDO
> 
> Microsoft *claims* "Passport 2.0" supports FIDO:
> 
> https://technet.microsoft.com/en-us/library/dn985839(v=vs.85).aspx
> 
> So, either you're wrong, or they're lying. I'm not a Microsoft fan and do
> not have any Windows 10 devices with which I can confirm or deny your claims
> or theirs. But you're alleging they suggested they'd support it and
> backpedaled. That's not the case:
> 
> "Microsoft Passport lets users authenticate to a Microsoft account, an
> Active Directory account, a Microsoft Azure Active Directory (AD) account,
> or non-Microsoft service that supports Fast ID Online (FIDO) authentication."

I am not wrong. :) Any Microsoft contact can confirm my previous post.

I did not suggest MS backpedaled. I work for a FIDO U2F device manufacturer,
(a FIDO alliance member) and closely follow Microsoft communication (and nearly
every software compatibiliy). I would love to use FIDO in Microsoft software...
but Microsoft just made a generic commitment about FIDO 2.0 (you'll find plenty 
of info about that everywhere). FIDO 2.0 is still a "draft of a draft" and there 
is no planned compatibility with FIDO "1.0" U2F (at least for now in the last 
drafts I am aware of).  

Remember we are talking about FIDO U2F here not about FIDO 2.0. There is no 
planned support for FIDO U2F in Microsoft tools. FIDO 2.0 still do not exist 
to this day -and finalized specifications won't be available soon-.  
Microsoft is "just" claiming their commitment to support the future FIDO 2.0 
specifications they are working on with other FIDO alliance members. That's 
great but using FIDO U2F anywhere in a Microsoft software won't be possible 
and FIDO 2.0 specifications are not even there... (you can't make a device
from the draft of a draft delivered to w3c or from any of the last internal 
drafts, we are still far from that), so...

Let's forget about Microsoft... 
Let's forget about FIDO 2.0...

Happy new year everyone! Let's hope Mozilla foundation will soon make a move 
about FIDO U2F support...

Comment 160

[Anders Rundgren]

(In reply to Frédéric MARTIN from comment #159)
 FIDO 2.0 still do not exist 
> to this day -and finalized specifications won't be available soon-.  
> Microsoft is "just" claiming their commitment to support the future FIDO 2.0 
> specifications they are working on with other FIDO alliance members. That's 
> great but using FIDO U2F anywhere in a Microsoft software won't be possible 
> and FIDO 2.0 specifications are not even there... (you can't make a device
> from the draft of a draft delivered to w3c or from any of the last internal 
> drafts, we are still far from that), so...
The W3C folks do not agree with that:
https://lists.w3.org/Archives/Public/public-web-security/2016Jan/0001.html
They seem fully committed rubber-stamping FIDO standards.

> Let's forget about FIDO 2.0...
This is no longer an option.

Comment 161

[Frédéric MARTIN]

(In reply to Anders Rundgren from comment #160)
> (In reply to Frédéric MARTIN from comment #159)
>  FIDO 2.0 still do not exist 
> > to this day -and finalized specifications won't be available soon-.  
> > Microsoft is "just" claiming their commitment to support the future FIDO 2.0 
> > specifications they are working on with other FIDO alliance members. That's 
> > great but using FIDO U2F anywhere in a Microsoft software won't be possible 
> > and FIDO 2.0 specifications are not even there... (you can't make a device
> > from the draft of a draft delivered to w3c or from any of the last internal 
> > drafts, we are still far from that), so...
> The W3C folks do not agree with that:
> https://lists.w3.org/Archives/Public/public-web-security/2016Jan/0001.html
> They seem fully committed rubber-stamping FIDO standards.
> 
> > Let's forget about FIDO 2.0...
> This is no longer an option.

There is nothing new there. Everything I just said is still true.
This is a thread about FIDO U2F support in Firefox. 
FIDO U2F specifications are finalized for USB devices.
Devices and web services are already there. 
It's working great on Google Chrome, it would be great to have an official Firefox support too.
(FIDO U2F support is already partially available through a Firefox plugin)

FIDO 2.0 specifications are not there and far from finished, FIDO 2.0 won't be compatible with FIDO U2F => this is not the subject here => read the draft submitted to w3C and you'll see there is no way for anyone to implement an authenticator from that (any FIDO Alliance member can confirm that, there is no close agenda to finalize FIDO 2)

So please focus on FIDO U2F support.
We will discuss FIDO 2 when finalized specifications will be available.

BTW, Anders : You did not answer about my previous question about you saying: (I quote:) "U2F people greatly oversell their stuff as well, particularly when it comes to the practicality of having a unique key for every site.  This will in reality create a huge advantage for providers like Google, Facebook, PayPal and Alibaba" (end of quote) => I guess you misunderstood this point => please read FIDO U2F specifications, there is no way for a web service to tell if the same U2F token -with other keys- is used on another service, this won't even be an hardware cookie :). Even the smallest website can implement U2F authentication (there is even a U2F plugin for Wordpress), and noone will have a larger view to link all identities or anything like that. (As a FIDO U2F manufacturer, we even decided to avoid key wrapping to be sure no one can accuse us of storing built-in secrets that could be shared to wrap keys inside keyhandles on a same token)

Comment 162

[Anders Rundgren]

(In reply to Frédéric MARTIN from comment #161)
> FIDO 2.0 specifications are not there and far from finished, FIDO 2.0 won't
> be compatible with FIDO U2F => this is not the subject here => read the
> draft submitted to w3C and you'll see there is no way for anyone to
> implement an authenticator from that (any FIDO Alliance member can confirm
> that, there is no close agenda to finalize FIDO 2)
OK, this makes the W3C submission even more strange...

> BTW, Anders : You did not answer about my previous question about you
> saying: (I quote:) "U2F people greatly oversell their stuff as well,
> particularly when it comes to the practicality of having a unique key for
> every site.  This will in reality create a huge advantage for providers like
> Google, Facebook, PayPal and Alibaba" (end of quote) => I guess you
> misunderstood this point => please read FIDO U2F specifications, there is no
> way for a web service to tell if the same U2F token -with other keys- is
> used on another service, this won't even be an hardware cookie :). Even the
> smallest website can implement U2F authentication (there is even a U2F
> plugin for Wordpress), and noone will have a larger view to link all
> identities or anything like that.
This is the "flip" side of U2F.  However, due to a certain "registration fatigue" this rather leads to the reliance on a few services providers that not only provide static linkable identities to third-parties, but (typically) also massively aggregate information.  That is, U2F's privacy-enhancing features are only achievable in lab-scale experiments or by people who are very privacy-aware.

Comment 163

[Jason Bradford]

Anders, please link to something that supports your claim with some detail. So far everything I am seeing from Mr Martin indicates that he knows exactly what he is talking about and has read all -or at least most- of the associated documentation and likely is involved at some level in the spec design discussions. Current web-scale implementations seem to be holding up without leakage just fine. If you are talking about metadata aggregation from the connection point of the client or client's gateway, well, good luck with designing a robust, scalable, excellent UX way around that. If there is a well-documented test that supports your claim, please share.

The claim if U2F people overselling as far as I have seen results in bad messaging from companies who signed up for the alliance because their misunderstanding of everything related made them think that that meant they could post the FIDO badge to their site and claim some level of compliance...but hopefully that aspect is getting more under control. If your opinions are related to information from the blogosphere, then you should find better sources because in the first 2 years, I read 1 post that indicated solid understanding even when those people had talked to the "right people".

At any rate, this bug that we're hijacking here is about adding U2F support to Firefox. Trying to porkbarrel a spec into this that has not yet been completed -let alone ratified- is counter to the objective of this bug. Feel free to open another bug asking for FIDO 2.0 support but understand there cannot be any motion on it until there is something to implement. I too look forward to the next generation but we will have to wait for it.

Comment 164

[Tony Arcieri]

> However, due to a certain "registration fatigue"

Anders, this claim is completely ludicrous. U2F enrollment is literally pushbutton. There is always going to be some user enrollment action on the user's part.

> this rather leads to the reliance on a few services providers

How does the three-legged dance of an OAuth2 enrollment flow solve "registration fatigue" in a way U2F's one-push enrollment does not? (Answer: it doesn't)

> that not only provide static linkable identities to third-parties

With holder-of-key proofs IdPs do not need to use static, linkable identities.

You are in "not even wrong" territory here, and this thread is not your personal soapbox to rant against U2F. This is a thread for discussing adding U2F to Firefox.

Comment 165

[Ian Young]

Take 

Comment 166

[Ian Young]

…and that's how I learned that bugzilla truncates(?!) text with emoji. Sorry for contributing to the noise, everyone. The intended message was:

Take. this. argument. somewhere. else.

Comment 167

[Alex Willmer]

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 168

[Martin Giger [:freaktechnik]]

(In reply to alex from comment #167)
> 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.

This was already noted in comment#100.

Comment 169

[Jason Bradford]

100 reasons to move forward with this implementation: https://fidoalliance.org/more-than-100-fido-certified-products-fuel-global-adoption/

Comment 170

[Mad Mac]

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 171

[Frédéric MARTIN]

(In reply to Mad Mac from comment #170)
> 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 ...

For now, they are filtering mozilla browser out. 
It still does not work if you change your browser user agent... 
The present add-on you are talking about do not support TLS channel ID and it could be a requirement on the Google portal server side. 

Now, Mozilla Foundation needs to :
- join the alliance (This process is supposed to be engaged *yawning*)
- implement FIDO U2F
- ask Google services if non-mandatory TLS Channel ID protection is a requirement for Google authentication server => implement it if needed

Comment 172

[My1]

but why does Mozilla need to join the Alliance to implement it?
I mean joining it doesnt hurt, but if I create a U2f-aware application must I join the alliance too or i will be sued or what?

I mean they can implement it without joing the alliance, can't they?

also about the plugin, it doesnt throw an error for registering an already registered key, which should usually return error 4.

Comment 173

[Erwann Abalea]

(In reply to My1 from comment #172)
[...]
> also about the plugin, it doesnt throw an error for registering an already
> registered key, which should usually return error 4.

From my understanding of U2F, there's no way for a software (browser/plugin) or an U2F-enabled service to detect it's registering on an already registered physical key. And this is so by purpose (privacy reasons).

Comment 174

[My1]

I was a bit too vague, sorry. I mean on the same account, and yes there is. Go to github with chrome and try to register the same u2f stick twice on an account. It will throw an error. As defined on yubico's pages client error 4 means either no key handle known (for auth) or a key handle is already known (for registration), but it isn't sent which one.

Comment 175

[Frédéric MARTIN]

(In reply to My1 from comment #172)
> but why does Mozilla need to join the Alliance to implement it?
> I mean joining it doesnt hurt, but if I create a U2f-aware application must
> I join the alliance too or i will be sued or what?
> 
> I mean they can implement it without joing the alliance, can't they?
> 

Oh, yes, no need to join the Alliance for Firefox devs to start implementation.

Mozilla Foundation will probably need to join when they will want to proclaim they are FIDO U2F compatible=> I am supposed they will have to pass at least interop tests.

But that was not the point, they need to move forward :) and joining the alliance could be a great start. By the way, Richard Barnes (Firefox Security Lead at Mozilla) already posted about the decision (2015, december):
"[...] 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.[...]"

Comment 176

[Frédéric MARTIN]

(In reply to Erwann Abalea from comment #173)
> (In reply to My1 from comment #172)
> [...]
> > also about the plugin, it doesnt throw an error for registering an already
> > registered key, which should usually return error 4.
> 
> From my understanding of U2F, there's no way for a software (browser/plugin)
> or an U2F-enabled service to detect it's registering on an already
> registered physical key. And this is so by purpose (privacy reasons).

(In reply to Erwann Abalea from comment #173)
> (In reply to My1 from comment #172)
> [...]
> > also about the plugin, it doesnt throw an error for registering an already
> > registered key, which should usually return error 4.
> 
> From my understanding of U2F, there's no way for a software (browser/plugin)
> or an U2F-enabled service to detect it's registering on an already
> registered physical key. And this is so by purpose (privacy reasons).

Hi/salut Erwann ;)

During the registration step, the user is already identified, so the server can send an array of keyHandles that are already associated/registered with the user account. The FIDO U2F device is able to check if this/these KeyHandle(s) already exist(s) [stored or wrapped] for this "app param" (hashed domain/url) and to return an error 4 if needed.

See bottom of this page for the error list:
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#error-codes
"
const int DEVICE_INELIGIBLE = 4;
[...]
DEVICE_INELIGIBLE of type int
    The presented device is not eligible for this request. For a registration request this may mean that the token is already registered, and for a sign request it may mean the token does not know the presented key handle.
"

Comment 177

[Frédéric MARTIN]

(In reply to My1 from comment #174)
> I was a bit too vague, sorry. I mean on the same account, and yes there is.
> Go to github with chrome and try to register the same u2f stick twice on an
> account. It will throw an error. As defined on yubico's pages client error 4
> means either no key handle known (for auth) or a key handle is already known
> (for registration), but it isn't sent which one.

You are right about this bug, Paweł Chmielowski's U2F addon for Firefox do not seem to correctly forward the full registration request including the list of already registered keyhandles that is sent by the server through js.

Pawel is following this thread but I will mail him directly about that, just in case. 
(I saw you already report that through Firefox addon review too. great.)

Comment 178

[Mark Capella [:capella]]

Drive-by / loosely interested in this area ...

Is this the proper [meta] bug for U2F? (I don't see :rbarnes cc:ed here. Is that an oversight?) Also logbot indicates that :jcj attended the FIDO Plenary recently and also might be consulted (?).

Not to put words in any-ones mouth ... there was a part of Richards communication not quoted above to the effect of "Personally, I have some reservations about implementing this ...".

Comment 179

[Frédéric MARTIN]

(In reply to Mark Capella [:capella] from comment #178)
> Drive-by / loosely interested in this area ...
> 
> Is this the proper [meta] bug for U2F? (I don't see :rbarnes cc:ed here. Is
> that an oversight?) Also logbot indicates that :jcj attended the FIDO
> Plenary recently and also might be consulted (?).
> 
> Not to put words in any-ones mouth ... there was a part of Richards
> communication not quoted above to the effect of "Personally, I have some
> reservations about implementing this ...".

Those were minor reservations :)

The whole post is here :
https://groups.google.com/forum/#!msg/mozilla.dev.platform/IVGEJnQW3Uo/Eu5tvyLmCgAJ
quoting:
>The FIDO Alliance has been developing standards for hardware-based
>authentication of users by websites [1].  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
>[2].  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
>[3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
>for U2F support in Gecko [6].  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 [7]. 
>
>Proposed: To implement the high-level U2F API described in the FIDO JS API
>specification, with support for the USB HID token interface.
>-----
>
>Personally, I have some reservations about implementing this, but I still
>think it’s worth doing, given the clear need for something to augment
>passwords.

>It’s unfortunate that the initial FIDO standards were developed in a closed
>group, but there is good momentum building toward making FIDO more open.  I
>have some specific concerns about the U2F API itself, but they’re
>relatively minor.  For example, the whole system is highly vertically
>integrated, so if we want to change any part of it (e.g., to use a curve
>other than P-256 for signatures), we’ll need to build a whole new API.  But
>these are issues that can be addressed in the W3C process.
>
>We will continue to work on making standards for secure authentication more
>open.  In the meantime, U2F is what’s here now, and there’s demonstrated
>developer interest, so it makes sense for us to work on implementing it.

>Thanks,
>--Richard 

It's rather positive. 

By the way, I am rather happy with the P-256 ECC default choice :) 
and since that post U2F over NFC and BLE specifications are nearly achieved, and
Mobile Google Chrome is already starting to support U2F over NFC it through its Authenticator...

I can continue to recommend Chrome everywhere to every contacts of mine... but that makes me a sad panda. :(

Comment 180

[My1]

(In reply to Frédéric MARTIN from comment #177)
> (In reply to My1 from comment #174)
> > I was a bit too vague, sorry. I mean on the same account, and yes there is.
> > Go to github with chrome and try to register the same u2f stick twice on an
> > account. It will throw an error. As defined on yubico's pages client error 4
> > means either no key handle known (for auth) or a key handle is already known
> > (for registration), but it isn't sent which one.
> 
> You are right about this bug, Paweł Chmielowski's U2F addon for Firefox do
> not seem to correctly forward the full registration request including the
> list of already registered keyhandles that is sent by the server through js.
> 
> Pawel is following this thread but I will mail him directly about that, just
> in case. 
> (I saw you already report that through Firefox addon review too. great.)

I found another one (I just write this here so if people try to use the plugin as base for the U2F support, which generally isnt bad, dont do the same bugs)
after a timeout (e.g. too slow to find stick), a retry seems to be impossible since it timeouts again, even if the stick is used properly. But the "inster/press U2f Device" notification disappears properly as it should. tested with both github and my own implementation (which bases off the Yubico U2f-api.js).

Comment 181

[Frédéric MARTIN]

Hi, JC Jones started new bug reports and updated other ones related / linked to this bug thread 
because he just confirmed on mozilla-dev forum that Mozilla team is making progress on FIDO U2F
support for Firefox ! I am sharing here the great news :)

Quoting JC Jones (Feb, 4th, 2016):

>We're making progress on implementing FIDO U2F in Firefox.
>The effort is split into a number of bugs at 
>present. First, a quick rundown of where we are:
>
>* The tracking bug for U2F support is Bug 1065729.
>* Bug 1198330 is to implement USB HID support in Firefox.
>* Bug 1231681 implements the WebIDL and the outline of the JS API. This bug’s code is in review.
>* Bug 1244959 completes the AppId/FacetId algorithm.
>* Bug 1245527 implements the state machines (USBToken) between the JS API and the USB HID support.
>* Bug 1244960 expands an NSS-based U2F token (NSSToken) for expanded integration and developer testing.
>
>A couple of notes/clarifications about how we’re planning to build U2F support:
>
>* The `window.u2f` API endpoint will only be available to code loaded from secure origins, in keeping
>with our policy for new features [1]. (This is also consistent with U2F support that is built into
>recent versions of Google Chrome.)
>* We are implementing the high-level JavaScript API version 1.1. The specification for v1.1 is not yet 
>published, but is already implemented in recent versions of Chromium [2].
>* For the time being, U2F support will be gated behind preferences and disabled by default.
>
>[1] https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
>[2] https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/cryptotoken/webrequest.js

[ Insert your favorite joyful emoticon here :) ]

Comment 182

[halindrome]

It would be great if this could get implemented!  I have a client that is requiring us to migrate to these keys and I don't want to move away from Firefox!

Comment 183

[Cliff DesPeaux]

I just purchased a Yubikey and I wish I could use U2F with it. What needs to be done to get this working?

Comment 184

[Anders Rundgren]

Since the browser-vendors "decided" for the market that client-certificates are bad and subsequently deprecated <keygen> and CertEnroll, it seems reasonable that the U2F implementation also supports "soft tokens".

Comment 185

[u573493]

I would also wish to be able to use my Yubikey for U2F trough Firefox, it would be appreciated if this got implemented!

Comment 186

[mike]

I super-want this as well. Lastpass is waiting on this before they roll out Yubikey support as well.

Comment 187

[tspencer]

A lot of enterprises want to move to U2F but can't realistically make that move until there is enough browser coverage. Chrome already has this, U2F for Edge is coming, but we need Firefox as well to make this possible.

Please, help us make passwords obsolete! :)

Comment 188

[Pawel Kraszewski]

Am I wrong, or mechanisms necessary to have U2F operational (HID access layer I presume) would also enable Trezor bitcoin wallet to be used without extra software wrapper (trezor-bridge)?

Comment 189

[terje]

Kraszewski, that's a good question, but you'd be wrong.

U2F does not use HID, and the Javascript API for it is U2F-specific.  Also, to be honest, I'm not sure if it would be a good idea to allow browsers HID-access.  It's a potential security-nightmare.

Comment 190

[My1]

terje while opening HID to JS is something I wouldnt like either let's not forget that javascript has access to the clipboard which is something that REALLY shouldnt be done security wise but that's another story.

my general opinion is unless something is intended to be used via js it shouldnt be, performance (a lot of websites cant be properly used on the phone because the js doesnt load properly etc, in case of no loading of CSS for some reason it's ugly but it works) and security wise, javascript has become, well let's just say annoying.

I dont know where you have the "U2F doesnt use HID" thing but I read on many occasions that U2F devices work as HID BECAUSE these are standard and need no extra drivers. for example here:
https://www.yubico.com/products/yubikey-hardware/fido-u2f-security-key/
let me quote:

"Identifies as a USB HID device which is standard on all computers"

so IF U2F really DOES use HID I think the browser HID link should be limited to U2F devices and not any more.

Comment 191

[Frédéric MARTIN]

to [e-mail] : No, Microsoft Edge team has no plan to implement FIDO U2F support. They are focusing on FIDO 2.0 support (not compatible with previous FIDO U2F and UAF) to push their "Hello" technology strange path... For now, FIDO 2.0 (renamed Web Authentication or WebAuthn) is not a reality and full of strange speculations... we can ignore it for now...

to [e-mail] : You are wrong, FIDO U2F USB devices ARE using HID and yes, Chrome already allow HID based communication https://developer.chrome.com/apps/hid. And that's not a security nightmare, FIDO U2F is a great opportunity to have easy and more secure web authentication.

to Pawel Kraszewski : That's an excellent question. Bitcoin Hardware Wallets like Trezor, Keepkey and Ledger products are using HID Chrome API. The availability of this API is a great choice from Chrome team. Regarding Firefox same support level... it depends how it will be implemented. Firefox/Mozilla team can decide to allow strict FIDO U2F data exchange without allowing larger HID communication. As far as I know, there is no official position on that point yet from the Mozilla team (adopting strict FIDO U2F communication feature versus offering a larger HID API).

Comment 192

[terje]

Sorry, I'm pre-morning coffee, and fumbled up the wording.  Point was that U2F - from the perspective of the exposed Javascript API - does not use or expose HID.  Nor is U2f the same as HID, HID is there, but just for identification to the computer, and as a transport-protocol for the raw U2F-messages on top of it.
Thanks for correcting, I'll make sure to get on the outside of proper amounts of coffee next time.

Comment 193

[My1]

(In reply to Frédéric MARTIN from comment #191)
> to [e-mail] : You are wrong, FIDO U2F USB devices ARE using HID and
> yes, Chrome already allow HID based communication
> https://developer.chrome.com/apps/hid. And that's not a security nightmare,
> FIDO U2F is a great opportunity to have easy and more secure web
> authentication.

U2F is okay, but general HID support might be a nightmare because if js can access the HID devices directly, depending on how it's done they could for example log your keystrokes even OUTSIDE the browser, and I am pretty sure you dont want that.

Comment 194

[Daner]

HID access in Chrome is limited to extensions, and I find this optimal for security.

Firefox should do the same, and, btw, it should have compatible extensions ;-)

Comment 195

[Pawel Kraszewski]

(In reply to terje from comment #192)
> Sorry, I'm pre-morning coffee, and fumbled up the wording.
Yes, without the morning 0.7l of coffee my eyes display "User is out of order. For satisfactory service please use the user next desk".

(In reply to My1 from comment #193)

> U2F is okay, but general HID support might be a nightmare [...]
Yes, bu we are not talking on exposing full HID api via JS, but about toolkit talking HID on the backside and exposing limited set of high-level ops on JS side.

Comment 196

[Frédéric MARTIN]

to Daner: Sorry, I don't think anyone understood your point about extensions... well... at least I don't :)

to My1: "depending on how it's done"... Uh... ok... like everything else... let's do it the right way :)
Of course, we are many to test what can be done through chrome.hid API, and for now, everything went smooth and good. By the way, if anyone went to dive into Chrome ways of doing: https://src.chromium.org/viewvc/chrome/trunk/src/device/hid/

to Pawel: "but about toolkit talking HID on the backside and exposing limited set of high-level ops on JS side" => We'll have to wait for the official Mozilla/Firefox team decision.

Comment 197

[My1]

(In reply to Pawel Kraszewski from comment #195)
> (In reply to My1 from comment #193)
> 
> > U2F is okay, but general HID support might be a nightmare [...]
> Yes, bu we are not talking on exposing full HID api via JS, but about
> toolkit talking HID on the backside and exposing limited set of high-level
> ops on JS side.
well I can live with that as long as it's fairly restricted and maybe gives options to advanced users to add even more limits because as I already said above a lot of js stuff is not very nice security wise, I mean js can read the clipboard, a malicious site could read the clipboard for passwords of a user using a pw manager, just as example.

Comment 198

[Pawel Kraszewski]

(In reply to My1 from comment #197)

> well I can live with that as long as it's fairly restricted and maybe gives
> options to advanced users to add even more limits because as I already said
> above a lot of js stuff is not very nice security wise, I mean js can read
> the clipboard, a malicious site could read the clipboard for passwords of a
> user using a pw manager, just as example.

Or even better, substitute certain clip contents with their own (hostile bank account number, bitoin address, etc)

Comment 199

[terje]

Personally, I'd be in favour of viewing U2F-support and general/generic HID-support as two separate – but overlapping – issues, for a couple of reasons;
 - U2F already has a defined JavaScript API, and it would aid adoption of U2f if Firefox supports the same.
 - U2F and HID can be conflicting, in a high-security environment, you might want to allow U2F, but lock down HID.
 - By the very nature of things, you need to expose one (U2F) and not the other (HID) to web pages.
 - Either can easily end up in lengthy discussions, and might be easier to get done with a not too wide focus.

When I mentioned HID as a potential security nightmare, that was intended to be in the context of implementing U2F, such as implementing U2F-login on a web page.  If a web page needed access to HID-stack directly, for authenticating users, it'd be a very different security-situation than what Chrome does now.

I'm not against all forms of HID-integration in browsers, and exposing HID to an extension/plugin that itself implements U2F, and exposes that into the javascript engine, might be a way to go.

That said, I do think there are potential security-issues with Chromes model as well.  One thing is trusting Chrome, and trusting the intentions of plugin-developers, but users will be trusting the technical abilities of the plugin-developers as well, not just their intentions.  I'm not trying to cry wolf here, but I do think it doesn't hurt to recognise that there are potential issues with HID-integrations, even if they're just open to plugin-developers.

Comment 200

[Frédéric MARTIN]

To Pawel et My1: No, you can't read clipboard from JS behind main/major/standard browsers users back at least without special browsers extensions and/or strong warnings on several browsers (even if you can write to it). It is out of scope here and wrong, please stop spreading this, thanx. You want to prove me wrong? Let's discuss this outside this forum and mail me a proof of concept. You won't.

To terje: The discussion is not about doing something new and non-secure, Chrome.HID API already provides this level of HID communication from a browser/JS without exposing HID direct stack, by excluding mouse and keyboards, and so on... Firefox team can decide to the same, or not. That's just the right debate here. By the way, I invite you to play with Chrome HID API and/or read the linked sources if you are concerned about this existing Chrome HID API.

Comment 201

[Anders Rundgren]

The consumer market have already settled on schemes using virtualized tokens which apparently is not requested here.

Comment 202

[m.bachmann]

@Anders: In company environments employees are often encouraged to use 2FA. And at least in our company, really everybody prefers the ease of use of a Fido U2F token over anything virtual, be it sms or an authenticator app. We use it every day - just not with Firefox, which is a pity.

Btw - where was that bounty counter? At $1260 (https://www.bountysource.com/issues/10401143-implement-the-fido-alliance-u2f-javascript-api?show_profile_modal=1)

Comment 203

[Anders Rundgren]

Hi [e-mail]
When I wrote virtualized I also included U2F as a possibility.  For mobile phone-based 2FA, virtualized credentials is probable 99%.

Comment 204

[tspencer]

(In reply to Frédéric MARTIN from comment #191)
> to [e-mail] : No, Microsoft Edge team has no plan to implement
> FIDO U2F support. They are focusing on FIDO 2.0 support (not compatible with
> previous FIDO U2F and UAF) to push their "Hello" technology strange path...
> For now, FIDO 2.0 (renamed Web Authentication or WebAuthn) is not a reality
> and full of strange speculations... we can ignore it for now...

I stand corrected, Frédéric, i had misunderstood their coming support for FIDO 2.0 as also including support for U2F, but i see that it does not nor is it planned. On the topic of FIDO 2.0, it appears that they have already implemented it in Edge in preview versions of Win10 (Preview Build 14291+), so that's good to know at least. Can't speak to how complete that implementation is or anything, but there seems to be something there anyway.

I saw from bountysource that you had outlined the path forward here as follows.
-------------------------------------

Now, Mozilla Foundation needs to :
- join the alliance (This process is supposed to be engaged *yawning*)
- implement FIDO U2F
- ask Google services if non-mandatory TLS Channel ID protection is a requirement for Google authentication server => implement it if needed

-------------------------------------

If I'm interpreting the FIDO members page correctly then it appears that the first bullet is done - Mozilla is a member of the FIDO alliance.

This thread is obviously about the second of those bullets, do we know what the main holdups are at this point for implementing U2F?

Comment 205

[tspencer]

After further reading it appears that the HID API library integration (Bug 1198330) is the largest hurdle at this point. I suppose I should take my question about blockers there.

Frédéric, your final bullet mentioned possible TLS Channel ID protection requirements, do you know if there is any new information on that topic?

Comment 206

[u550630]

"TLS Channel ID protection is a requirement for Google authentication server => implement it if needed"

We should implement it either way, don't you think?

Comment 207

[Frédéric MARTIN]

Hi Tspencer, 
Hi japerweiss.

Regarding optional TLS Channel ID protection implementation inside Firefox, I asked for it badly on other forum dev threads and I got rather non-sens answers from Mozilla devs. They said they want to wait for a  standard that will come soon (that has nothing to do with FIDO U2F... facepalm). So I hoped that this was mandatory on Google authentification servers. I asked Google team about it: they only used TLS Channel ID protection option for very few people inside their own team, not for the standard user, so I was not able to use this as an argument and I gave up. Now I am just waiting for FIDO U2F implementation on Firefox. As far as I know, mozilla devs do not plan to implement optional TLS Channel ID, so you'll have to ask for it if you want it too. 
To be fair : It does not add security on already deployed server that do not use it (Google, GitHub, DropBox...) but if one day you are planning to deploy FIDO U2F on your own sensible server, you'll probably have to make a choice and if you want the highest level of security with the best protection against MITM attacks, you'll probably have to refuse Firefox users.

Comment 208

[Frédéric MARTIN]

... and to be fair again: I know that there is a crisis inside Mozilla foundation, that people should be more involved, this is open source and everyone should be able to work for a feature they want... but I do not have the skill and the time to propose my own implementation... perhaps other people will help the dev team to understand it is not something that should be considereed as optional and that will offer their help. Chromium own implementation is open source, perhaps it will be added to Firefox later too.

Comment 209

[Tony Arcieri]

TLS channel ID is defunct. The new replacement standard is called Token Binding, and it's being standardized through the IETF:

https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04

Chrome is shipping an implementation of an earlier revision of the spec:

https://www.chromestatus.com/feature/5097603234529280

It can be enabled at:

chrome://flags/#enable-token-binding

I'd be happy to open a separate bugzilla issue for this if one doesn't exist already.

Comment 210

[Frédéric MARTIN]

Like I said. I gave up arguing. Let's have FIDO U2F support with or without TLS Channel ID. I don't care anymore. Chrome wins, anyway.

Comment 211

[Jason]

Wow.  This was submitted in 2014.  What is taking so long?  I didn't read this entire thread, but holy cow -- whatever technical or political problems you guys have need to be worked out.  All the world sees is that Chrome supports this and Firefox doesn't.

Comment 212

[Baptiste Mille-Mathias]

@jason this kind of comment is totally useless, if you want to make this feature real show us your code.

Comment 213

[Jason]

Yeah, that's the response I expected. That attitude is exactly why Firefox is in slow motion and increasingly losing marketshare to faster-moving vendors.

"OMG YOU do it" is the same brilliance that got Linux where it is in the desktop market: nowhere.

Comment 214

[mike]

Jason, if you actually read the thread, you'd see there is a plugin: https://addons.mozilla.org/en-GB/firefox/addon/u2f-support-add-on/ that works pretty well (not in Private mode).

Comment 215

[Laurențiu Nicola]

(In reply to Jason from comment #213)
> Yeah, that's the response I expected. That attitude is exactly why Firefox
> is in slow motion and increasingly losing marketshare to faster-moving
> vendors.
> 
> "OMG YOU do it" is the same brilliance that got Linux where it is in the
> desktop market: nowhere.

"I want this too" comments will always be shot down on the issue trackers of open-source projects. Bugzilla has a "vote" option you can use to show what features you're interested in. (Although I've never seen those votes making a difference.)

I'd love to see a UserVoice page for Firefox and or some other proof that users' feedback doesn't fall off into a black hole, but this is not the place to discuss it.

Comment 216

[Jason]

Not really a "I want this too" comment because I only use Firefox when I have to now. It's just an observation that this feature is going on 2 years without resolution. What is considered a reasonable time frame to get a relatively mainstream feature done?  After 2 years, why not just kill it?  The "let it stay in purgatory indefinitely" attitude seems to be a sickly symptom of the Mozilla community and one that doesn't jive with productivity. But it's pretty obvious my comments are going nowhere (much like the other comments on here), so I'm dropping it.

Comment 217

[Nibbles Dev Team]

We switched to Chrome in our office and we are really happy to use a faster and more evolute browser.
Bye Bye FF

Comment 218

[Chad]

After Nicolas polite response you'd think even the more narcissistic users would think twice before broadcasting their thoughts to ~400 devs on a bug tracking board.

Comment 219

[Tom Geompse]

It is quite nice to know that I am not alone, waiting for this ticket's resolution. A nice other feature in Chrome 29 will be available in Firefow 50, so there is still hope. Fido U2F is Chrome 38, eventually Firefox 59 will support it.

Comment 220

[mobile.microalex]

(In reply to Tom Geompse from comment #219)
> It is quite nice to know that I am not alone, waiting for this ticket's
> resolution. A nice other feature in Chrome 29 will be available in Firefow
> 50, so there is still hope. Fido U2F is Chrome 38, eventually Firefox 59
> will support it.
Tom, how do you know it isn't Firefox 65.5? (50/29*38)
Based on the current FF version number increasing speed, 40 was released in Aug last year, and 48 is the current version, we may have this feature 2 years later, not too bad , hmm?

Comment 221

[Tom Geompse]

(In reply to mobile.microalex from comment #220)
> (In reply to Tom Geompse from comment #219)
> > It is quite nice to know that I am not alone, waiting for this ticket's
> > resolution. A nice other feature in Chrome 29 will be available in Firefow
> > 50, so there is still hope. Fido U2F is Chrome 38, eventually Firefox 59
> > will support it.
> Tom, how do you know it isn't Firefox 65.5? (50/29*38)
> Based on the current FF version number increasing speed, 40 was released in
> Aug last year, and 48 is the current version, we may have this feature 2
> years later, not too bad , hmm?

It is so wrong, your 50/29*38 implies that previous versions affect future changes. I must believe in my 50-29+38 for its optimistic "Mozilla does what Google does, but 5 years later".
Basing on https://wiki.mozilla.org/RapidRelease/Calendar they seem to move from 1month to 2months between 2 versions, so I would say it is 4 years from now.

Meanwhile I will do U2F with Native Messaging (FF50). Because it rocks.

Comment 222

[Kevin Cox [@kevincox:matrix.org]]

I've refrained from commenting for a while but I'm afraid this discussion of Mozilla/Firefox process doesn't belong in this bug. If you wish to provide constructive criticism about how Firefox is developed there are mailing lists for that.

Please remember that this issue isn't being worked on due to lack of interest, it is pretty clear to me that this is a desired feature by everyone in this thread. The problem is that all available resources are being used elsewhere in places that are deemed more critical by the people providing those resources. If you want to provide resources yourself I'm sure they would be welcomed. You can contribute patches yourself, or you can hire someone to do that for you. Please don't complain about things not being worked on when the problem is due to lack of resources, all you are doing with your comments is consuming more. If you want to be helpful contributing is likely the best way.

Thanks, Kevin

Note: I am not affiliated with Mozilla in any way.

Comment 223

[Anders Rundgren]

(In reply to Tom Geompse from comment #221)

> Meanwhile I will do U2F with Native Messaging (FF50). Because it rocks.

Native Messaging indeed rocks and would IMO have been a better path to U2F than building support directly in the browser. However, Native Messaging haven't gotten any love from the "true" Web architects so it appears to be a temporary solution.

https://bugzilla.mozilla.org/show_bug.cgi?id=1267362

Comment 224

[Uwe Mock]

Kevin,

you're saying it's more critical to remove working code from Firefox (e.g. Hello) than implementing something that has been requested for years - and that should be not so difficult to build as an OS implementation already exists?

Comment 226

[Asa Dotzler [:asa]]

It looks like Yubico is recommending people switch to Chrome because Firefox lacks this support. https://twitter.com/DrSynAck/status/783957757053562880

Comment 227

[Jason]

Well, it wouldn't make sense to recommend a browser, like Firefox, that doesn't support a feature.

Comment 228

[Anders Rundgren]

There is very little proof that the 2FA world of the future in general will be powered by specific authenticator devices.  File- and TEE-based keys will be the mainstream.  Mozilla could start this transition.

Comment 229

[Uwe Mock]

Anders, I do not know  of any service or system that uses a file based key for 2FA, and TEE as a concept for 2FA was completely new to me.

Comment 230

[Anders Rundgren]

Hi Uwe, 500 million Chinese users of mobile payment systems use file based keys for authorizing transactions.  In Sweden (my country of origin), half of the population use a mobile phone based PKI client for logging in to e-government services, on-line banking, and most recently for authorizing Person-2-Person payments.

From my (citizen/consumer) perspective, file-based keys appear to be close to a de-facto standard which FIDO won't be able to change.  With TEE-protected keys, security of virtualized tokens will meet most organizations' needs.

Comment 231

[Uwe Mock]

Anders, thanks for pointing this out. The only file based authentication system I am aware of is the ELSTER system used by the German financial authorities, but this is single factor authentication, not 2FA.

Comment 232

[Uwe Mock]

One more point on that - even if we're moving towards a philosophical discussion on MFA.

A file based second factor is just another "I know" factor from my point of view ("I know what that file must contain"). The "I have" factor should not be easily copyable, and this should typically be a hardware device (such as a bank card or a USB token).

Comment 233

[Anders Rundgren]

Uwe, yeah the definition of what 2FA is apparently varies :-)

You are essentially saying that this is not good enough:
https://developer.android.com/reference/android/security/keystore/KeyProtection.html

Reality check:
French banks only offer user-id/passwords for authentication to on-line services.  In addition they allow you giving these credentials to third-party service providers acting on your behalf!

I think security experts also are unfair solely blaming the CEO of Yahoo! for the recent theft of 500 million passwords when the ultra-advanced computing platforms that we have today doesn't support 2FA out-of-the-box.  Aren't these devices actually UNFIT for the tasks they are marketed to be used for?

Comment 234

[Frédéric MARTIN]

Hi Uwe and all, we all know -yes, Anders, you know it too- that file based auth is not secure nor easy to deploy and that TEE is a practical joke (Everyone should try to deploy his own TEE based solution before talking about how great TEE is... please...) We should all stop feeding the swedish Troll, we already have Linkedin for that, you can join the party there :) FIDO U2F is an excellent solution, U2F USB tokens are here. They work. U2F NFC cards are here. They work (on Android only of course). I am testing the first U2F Bluetooth (some with USB too) devices prototypes and again: great all in one solutions (iOS support is coming, FIDO Alliance provides iOS source for specs tests now). I am even working on using FIDO API with tweaked non-FIDO devices to provides enhanced features... so please stop answering Anders here and for personal reply mail me at [e-mail]. *Stop using this bugzilla thread*

Comment 235

[Anders Rundgren]

Frederic et al,

U2F seems to be designed for virtualization since the domain concept performs the shielding needed rather than relying on complex access control schemes like GlobalPlatform.

My new Huawei P9 Lite Android (V6) phone claims having "hardware backed keys" (presumably via some kind of TEE-scheme), so we are probably only a few Android/Chrome upgrades away from actually having U2F support out-of-the-box (but still in the box).

Anders
Swedish Troll - https://www.youtube.com/watch?v=zAG5OvGZZOs

Comment 236

[Jeffrey Walton]

> My new Huawei P9 Lite Android (V6) phone claims having "hardware backed
> keys" (presumably via some kind of TEE-scheme), so we are probably only a
> few Android/Chrome upgrades away from actually having U2F support
> out-of-the-box (but still in the box).

Likely ARMv8 and AArch64 or Aarch32 execution environments with trust zones, supervisor mode, etc. Looking at the P9 specs, its an Cortex-A53, which is ARMv8.

Jeff

Comment 237

[Anders Rundgren]

It is still unclear to me how embedded security solutions like above will deal with third-party browsers since there probably should be some kind of trust relation between the browser and OS.

Apple have restricted third-party apps from using vital parts of the security platform Apple created for their Apple Pay system.

Comment 238

[Jeffrey Walton]

(In reply to Anders Rundgren from comment #237)
> It is still unclear to me how embedded security solutions like above will
> deal with third-party browsers since there probably should be some kind of
> trust relation between the browser and OS.

My bad... I was not making pro/con args or stating anything other than the likely candidates that provided the security features.

> Apple have restricted third-party apps from using vital parts of the
> security platform Apple created for their Apple Pay system.

Be careful here... Its easy to conflate or commingle vendor lock-in, anti-competitive practices and control of the data with security implementation. Google does it too. I imagine Microsoft is also doing it on the Windows platform, and Amazon is doing it on their platform. Its one of the reasons ISIS is no longer viable.

As far as I know, with a sufficiently adequate platform (like ARMv8 and an aware OS), all you need is a secure applet to handle the transaction. Any consumer program should be able to call on the services and effect a transaction as long as the user authorizes it. That Apple, Google, et al _only_ allows their programs to do it is just the lock-in and anti-competitive practices.

Comment 239

[Anders Rundgren]

(In reply to Jeffrey Walton from comment #238)

<snip>

> As far as I know, with a sufficiently adequate platform (like ARMv8 and an
> aware OS), all you need is a secure applet to handle the transaction. Any
> consumer program should be able to call on the services and effect a
> transaction as long as the user authorizes it.

I'm not sure I fully buy into this.  It is the *relying party* that ultimately trusts client keys, right?  If keys are used by for RPs unknown programs isn't there is a risk that *their* users in some way are screwed (which RPs of course do not want)?

I may be (totally) wrong, but to me U2F appears to be sharing this particular problem with its more traditional cousins.

Comment 240

[V. Korn]

Another genius decision - make U2F available only in e10s mode - https://bugzilla.mozilla.org/show_bug.cgi?id=1297552#c12
This is especially funny since Mozilla constantly have to disable e10s first for ru locales due bugs, then for users "which seen tab spinner to frequent".

Comment 241

[Anders Rundgren]

Intel seems to have an excellent solution for storing U2F keys:
https://software.intel.com/en-us/sgx

Comment 242

[Jeffrey Walton]

(In reply to Anders Rundgren from comment #241)
> Intel seems to have an excellent solution for storing U2F keys:
> https://software.intel.com/en-us/sgx

As far as I know, all the browsers lack protected storage. The only storage options available are the indexed-db type.

Data has three states: (1) data at rest, (2) data in transit and (3) data on display. Lack of protected storage is one of the reasons web apps are mostly relegated to low value data. They don't do a good job of protecting the data in state (1). They also do a rather poor job for state (2) due to curiosities like "Public Key Pinning Extension for HTTP with Overrides" (RFC 7469).

Comment 243

[Anders Rundgren]

Apparently my request for embedded U2F (transcended into W3C Web Authentication) support is/was already in the planning phase:
https://groups.google.com/forum/#!msg/mozilla.dev.platform/F0rCRF8z87E/oODctynwCwAJ

That's awesome!

Anders

Comment 244

[Jason]

Google determines that security keys, like the standard described in this thread, are the best version of 2FA in terms of people actually using it consistently:

http://arstechnica.com/security/2016/12/this-low-cost-device-may-be-the-worlds-best-hope-against-account-takeovers/

Comment 245

[Anders Rundgren]

(In reply to Jason from comment #244)
> Google determines that security keys, like the standard described in this
> thread, are the best version of 2FA in terms of people actually using it
> consistently:
> 
> http://arstechnica.com/security/2016/12/this-low-cost-device-may-be-the-
> worlds-best-hope-against-account-takeovers/

Yes, it seems that the people subscribing to this issue believe that 50K Googlers are defining the "market", while 5M Swedes and 500M Chinese using embedded "App" based security solutions do not.

Another way of describing this is that the US (together with France) is the great laggard when it comes to large scale use of 2FA.

This in no way means that FIDO/U2F is bad, I'm just questioning the market's interest in buying external security tokens, particularly for consumers/citizen solutions.

Related Estonian eID project:
http://www.zdnet.com/article/android-ios-secure-id-estonia-says-its-taking-digital-authentication-to-new-levels/

Related Luxenbourg banking project:
https://www.bil.com/byebyetoken/index-ios-en.html

Related Apple project:
http://www.recode.net/2016/12/6/13863670/apple-pay-digital-id-cards-transit-japan

The French "disaster" project:
https://www.linkedin.com/pulse/la-france-country-without-identity-anders-rundgren

Comment 246

[Uwe Mock]

Anders,

you're saying that people are not interested in buying a hardware item that is currently entirely useless because there is no software support. This is exactly what this thread is trying to change.

I bought a hardware token just because I'm a techie, and it was quite cheap. I have it in the drawer so I can use it once there is software support in the browser that I usually use.

With your type of argument, you could also claim that people have no interest in electric cars because fuel based cars are such a huge success. This is ridiculous.

Comment 247

[Anders Rundgren]

(In reply to Uwe Mock from comment #246)
> Anders,
> 
> you're saying that people are not interested in buying a hardware item that
> is currently entirely useless because there is no software support. This is
> exactly what this thread is trying to change.
> 
> I bought a hardware token just because I'm a techie, and it was quite cheap.
> I have it in the drawer so I can use it once there is software support in
> the browser that I usually use.
> 
> With your type of argument, you could also claim that people have no
> interest in electric cars because fuel based cars are such a huge success.
> This is ridiculous.

No, this is an (deliberate?) incorrect interpretation of my message which simply is that Mozilla should rather consider the 99℅+ market for U2F.  Google will most certainly do that as well but right now they cannot since that would create bad vibes within FIDO. Mozilla are seldom first with anything so this looks like an OPPORTUNITY!

Comment 248

[Jeremiah Lee]

I don't work at Google. My employer is considering switching to U2F and I don't want to have to switch to Chrome.

Comment 249

[github]

Have you seen that there seems to be already support for U2F in Firefox?

Comment 250

[My1]

there isnt really U2F Support "in" firefox, there's "just" an addon. and even though it helps it isnt as great as direct browser support

Comment 251

[github]

I don't use the add-on at all. It's a plain Firefox installation 50.1.0 and I'm able to use U2F in Fastmail, Github and Gmail.

Comment 252

[My1]

this is surprising, well actually I down'ed myself to ESR because Instantfox doesnt work anymore, but maybe I should try to set up a portable Firefox and try. but thanks for the info

Comment 253

[aj]

(In reply to github from comment #251)
> I don't use the add-on at all. It's a plain Firefox installation 50.1.0 and
> I'm able to use U2F in Fastmail, Github and Gmail.

I am on FF 50.1.0 and I tried Github @ https://github.com/settings/two_factor_authentication/configure but it shows : 

>  This browser doesn’t support the FIDO U2F standard yet. We recommend updating to the latest Google Chrome to start using security key devices.

Comment 254

[Frédéric MARTIN]

Let's have an all in one post / news :

(In reply to github from comment #251)
> I don't use the add-on at all. It's a plain Firefox installation 50.1.0 and
> I'm able to use U2F in Fastmail, Github and Gmail.

1)
No. You made a mistake somewhere. Firefox still do not support FIDO U2F natively.
Not in the stable branch (50.1.0) not in the beta (51 beta 10) no in the alpha (53 alpha 1)

Firefox devs are still working on FIDO U2F support. They did not give up. It will take some time.

For now, the only solution for firefox is to use this third-party addon (thanx again Paweł Chmielowski):
https://addons.mozilla.org/fr/firefox/addon/u2f-support-add-on/
This is working great but not on all servers (AFAIK, server side filter issues, nothing related to the addon).

Fun fact about U2F addons: since Apple still doesn't give a f*** about anything, there is now a first FIDO U2F add-on for Safari on OS X and macOS Sierra (Sierra is not "OS X" anymore. Please just don't ask.)

(In reply to Anders Rundgren from comment #247)
> > blah blah

2)
My favorite Swedish Troll is back ! Merry Xmas to you Anders! (and to all of you by the way!)

More seriously, there are already smart phone app based FIDO U2F solutions, so... your comments makes no sens at all: you are / will be able to use FIDO U2F (over BLE) smartphone apps if you want. Everyone can be happy !

Speaking about large deployment in China and so on, I am in contact with several major actors there and tested different implementations... FIDO U2F is happily welcomed there too. Feitian/FTSafe even recently decided to join FIDO alliance board members.

--

Regarding FIDO U2F dev status and FIDO news...

3)
New recent December milestone : FIDO U2F 1.1 specifications promoted to Implementation Draft Specification
• Change USB transport to conform to ISO7816-4
• NFC (ISO7816-4) support
• Bluetooth Low Energy support

Out of scope here, but first NFC and BLE products are working great. I don't know Firefox agenda about this kind of non-USB support yet. I guess it will come later.

4)
FIDO 2 / WebAuthn

There are hopes (not officially confirmed yet, but the will seems to be really back/present now!) that FIDO U2F solutions will be compatible with the new FIDO2 / WebAuthn specifications after all one way or another. More info on this "soon" (c)

--
Fred

Comment 255

[Anders Rundgren]

(In reply to Frédéric MARTIN from comment #254)

> (In reply to Anders Rundgren from comment #247)
> > > blah blah
> 
> 2)
> My favorite Swedish Troll is back ! Merry Xmas to you Anders! (and to all of
> you by the way!)
> 
> More seriously, there are already smart phone app based FIDO U2F solutions,
> so... your comments makes no sens at all: you are / will be able to use FIDO
> U2F (over BLE) smartphone apps if you want. Everyone can be happy !

No, I think way more people would be happy if they could use U2F without any investment also on a PC. The huge work Mozilla put into WebCrypto ought to match some 75℅ of the code needed.

From a product management point of view it makes perfect sense to take such a path.

Comment 256

[Bart Genuit]

Just contributed to the bounty here:
https://www.bountysource.com/issues/10401143-implement-the-fido-alliance-u2f-javascript-api

Come on guys, let's get this thing on the rails!

Comment 257

[Dan Callahan [:callahad]]

Facebook just announced support for U2F: https://www.facebook.com/notes/facebook-security/security-key-for-safer-logins-with-a-touch/10154125089265766

However, according to Hacker News comments, it does not appear to be offered to Firefox users even with the U2F add-on installed.

Comment 258

[Adi]

(In reply to Dan Callahan [:callahad] from comment #257)
> Facebook just announced support for U2F:
> https://www.facebook.com/notes/facebook-security/security-key-for-safer-
> logins-with-a-touch/10154125089265766
> However, according to Hacker News comments, it does not appear to be offered
> to Firefox users even with the U2F add-on installed.

for me it worked to register and use my Yubikeys on FB but i had to use the User Agent Switcher to force Firefox to pretend it was Chrome, after that it worked just fine with the U2F support addon.

Facebook is blocking the Firefox user agents from using U2F.

Comment 259

[dev]

(In reply to Adi from comment #258)
> Facebook is blocking the Firefox user agents from using U2F.

This totally makes sense from a UI/UX perspective. The majority of Firefox users don't use the plugin, so displaying the option to them will lead to unnecessary confusion. 

(On the other hand, a additional check for the plugin should be possible, but is probably not their highest priority, given the adoption rate of the plugin.)

I am happy that Facebook jumped on board, especially given the fact of it's increasing importance as single sing-on provider for other platforms. I also think this could be seen as another sign to give the Firefox implementation a higher priority. ;-)

Comment 260

[Fabrizio]

(In reply to Adi from comment #258)

> Facebook is blocking the Firefox user agents from using U2F.

How is it supposed to work ? You mean with U2F add-on right ? In this case, (no flame) how can you trust an add-on to manage a so important security aspect ? I am NOT saying that the author will spy .. I just want to understand ...
I am waiting an official Mozilla release.
Thanks

Comment 261

[Frédéric MARTIN]

(In reply to Fabrizio from comment #260)
> (In reply to Adi from comment #258)
> 
> > Facebook is blocking the Firefox user agents from using U2F.
> 
> How is it supposed to work ? You mean with U2F add-on right ? In this case,
> (no flame) how can you trust an add-on to manage a so important security
> aspect ? I am NOT saying that the author will spy .. I just want to
> understand ...
> I am waiting an official Mozilla release.
> Thanks

For your information, this add-on is open source :
https://github.com/prefiks/u2f4moz

and the real security (accounts keys, challenge signature) 
are done by the U2F token, usually inside its secure element / smart card chipset.

Comment 262

[Adi]

(In reply to Fabrizio from comment #260)
> I am waiting an official Mozilla release.
> Thanks

Firefox already has some bits of U2F built-in for testing and they are functional with a browser built-in software token - you can enable them via about:config - the U2F internal API is functional it's just the USB communications bit that's not finished yet.

If you want to test the u2f soft token built-in into Firefox (yes, even FF v50 has this) then enable in about:config

security.webauth.u2f
security.webauth.u2f_enable_softtoken

and reload the page. Try testing U2F now.
(make sure to disable softtoken when you're finished with tests)

The U2F API works, but beware that the soft token is only for testing. The token key has a lifetime of just 24 hours and is valid only for 24 hours before and after from the moment it's generated. (+/- 24 hours to allow for time sync variations)
 After that, the token key expires, is reset and a new key is generated when it's requested next so it won't be valid for long-term use. It's perfectly fine for testing u2f web site functions though.

Also, the built-in software token doesn't need the u2f support addon to be installed, just turn on those browser preferences.

Comment 263

[My1]

if you ask me there should be just a js call or whatever which u2f browsers answer with a true or whatever so websites dont need to keep up with what browsers do and dont support u2f, but just call that "U2F ping" as I may call it and if it answers then we can sho u2f if not, well, then not, obviously, or rather there should be general functions regarding whether js feature xy is available or not

Comment 264

[Brad Hill]

Hi, Facebook U2F implementation team here. We would love to have people using U2F with Firefox on Facebook.  

Launching a feature like this on a site as complicated as Facebook is a big project and we prioritized getting it out to users as soon as possible.  Doing feature-detection of a U2F API instead of User Agent sniffing would have required additional engineering effort due to how our system already works.

Given that the U2F add-on has only been installed in the low thousands of times ever, it just wasn't something we were able to prioritize supporting, and we don't want to have a broken experience for everyone else on stock Firefox.  It isn't ideal, but I am confident that the people who know how to install that add-on or flip the prefs to turn on built-in support can also spoof their User Agent string for now, and I did personally test and make bugfixes for this to work.  Hopefully we won't have to do this for much longer.

Comment 265

[My1]

@Brad Hill one way of avoiding a too bad experience for anyone would be if the user is on a Firefox with a compatible version that you tell them that they can use u2f with that addon and a button to tell FB that you know, acknowledge the warning and continue or something like that.

Comment 266

[My1]

or you could just say that "U2F may not work with your browser unless an add-on or similar is used" that lets users continue no matter the browser so if they have a browser which happens to play U2F either via addon or whatever can just click through and get their security.

Comment 267

[Adi]

(In reply to My1 from comment #263)
> if you ask me there should be just a js call or whatever which u2f browsers
> answer with a true or whatever[...snip...]

that "JS call" is a work in progress to become a W3C Standard but it's not finished yet.

https://www.w3.org/TR/webauthn/#api

basically, in the future a web site will be able to use JS to check if the browser provides a WebAuthentication API interface.

work on that standard is not finalized yet, so in the meantime web sites use whatever they can to identify browsers that support this.

Comment 268

[Jeffrey Walton]

(In reply to Fabrizio from comment #260)
> (In reply to Adi from comment #258)
> 
> > Facebook is blocking the Firefox user agents from using U2F.
> 
> How is it supposed to work ? You mean with U2F add-on right ? In this case,
> (no flame) how can you trust an add-on to manage a so important security
> aspect ? I am NOT saying that the author will spy .. I just want to
> understand ...
> I am waiting an official Mozilla release.

+1. I don't like conferring trust. Its a core security feature, and the browser should supply it.

It would be different if Mozilla performed the security review on the plugin and accepted the risk. But they don't vet the plugin, and they shed the risk. Mozilla's actions and position indicate users should not trust it either.

Its nothing personal against this plugin or the others. Conferring trust is a bad idea, and its gotten folks into trouble more than once.

Jeff

Comment 269

[Anders Rundgren]

(In reply to Adi from comment #262)
> 
> The U2F API works, but beware that the soft token is only for testing. The
> token key has a lifetime of just 24 hours and is valid only for 24 hours
> before and after from the moment it's generated. (+/- 24 hours to allow for
> time sync variations)

To me this sounds like complete BS since the code most likely is derived from the WebCrypto API. If WebCrypto ever was a good idea (?), a "soft token" U2F would be just fine.

Comment 270

[Frédéric MARTIN]

hi Anders again, please, again, keep your Troll tendencies out of this thread. :)
We all know you believe software protection is good enough for many people... but here we are talking about U2F, a new standard, pushed and adopted by many web services providers through hardware / secure elements. This is not BS, this is standard simple PKI with REALLY secure key storage and usage. If you don't want to talk about official FIDO U2F hardware support inside Firefox, please go to Linkedin, I will continue to read you there :) The soft token is only for testing, for now, everyone want to have nearly the same security level through different browsers when FIDO U2F is involved. Thanx.

Comment 271

[m.bachmann]

> hi Anders again, please, again, keep your Troll tendencies out of this thread. :)

I couldn't agree more. Since so long, whenever somebody tries to get productive on the topic, you, Anders, talk about your software protection stuff. Open your own thread or smth, please don't interfere here where we talk about U2F implementation. Thank you!

Comment 272

[Adi]

(In reply to Anders Rundgren from comment #269)
> To me this sounds like complete BS since the code most likely is derived
> from the WebCrypto API. If WebCrypto ever was a good idea (?), a "soft
> token" U2F would be just fine.

for testing u2f functions when developing a website you are right, a soft token is just fine as it supplements the physical presence of a hardware token. Web site developers can use it to test that their sites work with U2F without having to buy U2F keys.

for security though, it's just as vulnerable as any other password since the private key of the software token would be vulnerable to copying from disk/memory and other local-system attacks. This is why the softtoken is valid for maximum 24 hours. 

On a physical U2F key the private key never leaves the token as it is stored inside a hardware secure element on chip. The hardware key will only sign requests for authentication but will never reveal the private key that it uses for this process. Basically, an U2F key is a HSM that requires user interaction and approval for each signing operation.

Comment 273

[Anders Rundgren]

Of course, 800 million Chinese folks using "soft payment tokens" were wrong and will burn in hell :-)

Anders
Old ****, Inventor, Troll, Cat herder, You name it
Latest "delirium": https://cyberphone.github.io/doc/web/REST-in-peace.html

Comment 274

[Tony Arcieri]

I am (and many others are) subscribed to this issue to see updates on Firefox U2F progress.

The off-topic trolling by Anders Rundgren is extremely annoying. Are any of the moderators capable of banning him so we can keep the issue on-track?

Comment 275

[Anders Rundgren]

I will remove myself from this list.  It seems anyway to be focusing on the less than 0.5% of the Mozilla user base that will buy a USB token.

Comment 276

[Jason Bradford]

To be clear, U2F is not = to USB tokens. Multiple mobile devices are shipped as functional U2F authenticators. The recently-released Macs and quite a few Windows machines with biometric sensors and TPM/Secure elements are natively capable of being U2F authenticators. Whether this thread's intent to enable U2F functionality for anything beyond a USB key is outside my scope of awareness but this claim is technically false. There are millions od U2F-capable authenticators currently in use on the internet and it is simply up to the developers of application to choose to enable that functionality or not.

Comment 277

[Jason]

I believe this bug either needs a timetable or outright rejection. It's been hanging open long enough in limbo that it needs finality.

2.5 years ought to be enough time to decide the fate of this bug. If it's not happening and that decision is final, then that needs to be made public so users and developers don't waste anymore time with Firefox.

Comment 278

[Dannyzen]

https://trends.google.com/trends/explore?q=u2f is showing a gradual but relevant rise in the interest for U2F
https://addons.mozilla.org/en-US/firefox/addon/u2f-support-add-on/ has ~ 20,000 users 

I understand that "some" of the functionality for U2F is implemented but as an end user the functionality isn't fully supported without additional tools. 

I, as a passionate supporter of Mozilla and long-time Firefox ask for clarification regarding full U2F support. Is this functionality that is planned for a future Firefox release?

Comment 279

[Adi]

(In reply to Dannyzen from comment #278)
> I, as a passionate supporter of Mozilla and long-time Firefox ask for
> clarification regarding full U2F support. Is this functionality that is
> planned for a future Firefox release?

according to https://wiki.mozilla.org/Security/CryptoEngineering#Web_Authentication
full native U2F support is scheduled for sometime in Q1-Q2 2017.

and a side (and sad) note: Firefox 52 has been launched without USB support for U2F and since v52 is announced to be the last ever feature release for WinXP/XPPOSReady/Vista then that means these OSs will NEVER get native USB U2F support in Firefox and the only way to have it will remain via the addon.

https://support.mozilla.org/t5/Install-and-Update/Important-Firefox-is-ending-support-for-Windows-XP-and-Vista/ta-p/31270

Comment 280

[Kuba Niewiarowski]

(In reply to Adi from comment #279)
> and a side (and sad) note: Firefox 52 has been launched without USB support
> for U2F and since v52 is announced to be the last ever feature release for
> WinXP/XPPOSReady/Vista then that means these OSs will NEVER get native USB
> U2F support in Firefox and the only way to have it will remain via the addon.

You should never consider giving XP users illusion of safety as a good thing.

Comment 281

[Adi]

(In reply to Kuba Niewiarowski from comment #280)
> You should never consider giving XP users illusion of safety as a good thing.

i know, but...well, unfortunately here in .ro most of the public sector is still stuck in the XP era. The Customs authority even forces online users to install jre 1.6.0_12 if they want to use the EU EORI system and newer jre versions are not accepted.

Also, since the Microsoftgate scandal, pretty much nobody in the capital wants to sign a new volume licensing contract for government and regional public institutions so we're abandoned and forced to buy at whatever retail prices we find them.

 Oddly, i think that while for the public IT infrastructure it was (and still is) a disaster, for Microsoft itself it was a huge marketing "success" because of the *percentage* of licenses sold at full retail prices. (pretty much all of them). If you look on the national e-procurement portal ( e-licitatie.ro ) under Award procedures -> Direct Acquisitions -> Awarded Direct Acquisitions (search for "windows") you'll see a ton of purchases where public institutions are buying whatever windows/office licenses they can, piecemeal, at retail prices because the government licensing program is practically crashed and non-functional since 2009. (note: prices there are without 19% VAT)

/end rant

Comment 282

[u593608]

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 283

[David Ross]

Linking in another healthy Google Group discussion on the intent of implementing FIDO U2F API not already in this thread https://groups.google.com/forum/#!topic/mozilla.dev.platform/IVGEJnQW3Uo

Includes clarity on the behavior experienced via TLS Channel ID in Google products and their momentum towards IETF Token Binding spec.

Comment 284

[Jeffrey Walton]

Congrats to the Mozilla team. Thank you.

Comment 285

[My1]

@Jeffrey (#284) this bug is not over. just another of the dependency has been cleared, but it is another step towards FINALLY getting U2F natively in FF.

grats for making this step btw.

Comment 286

[David Ross]

https://addons.mozilla.org/en-US/firefox/addon/u2f-support-add-on/

is broken in 56.0b2

As an NDA'd Mozillian, this add-on has been the only route left to me to login to use Discourse & Airmo inside Fx via Github using U2F/Yubikey. I don't have a smartphone. And as referred to in comment #286 a Yubikey is blocked across Google's suite.

Comment 287

[V. Korn]

Just to keep folks informed - with latest Nightly i can successfully use my HyperSecu U2F token with Firefox. So i suggest everyone who purchased tokens in advance to go test it now.

Comment 288

[Laurențiu Nicola]

Works for me on Win 10 x64 with the U2F test page and github.com. Google sites still do User Agent detection, and I haven't tried spoofing it.

If anyone else wants to test this and missed the comment on the related issue, the following settings need to be enabled in about:config:

security.webauth.u2f
security.webauth.webauthn
security.webauth.webauthn_enable_usbtoken

Thanks for all the work on this!

Comment 289

[u544622]

Works for me too.

* Ubuntu 17.04
* Yubikey 4
* https://demo.yubico.com/u2f

Comment 290

[Marcos H. Alano]

I tested on Ubuntu 17.04 and 17.10 using nightly release from the PPA on Yubico U2F demo page but doesn't work. I will test again with the latest nightly release on Github

Comment 291

[Kyle]

- 57.0a1 (2017-09-16) (64-bit)
- Windows 10
- YubiKey NEO

I have enabled the following in about:config

security.webauth.u2f;true
security.webauth.webauthn;true
security.webauth.webauthn_enable_softtoken;true
security.webauth.webauthn_enable_usbtoken;true

It does *not* work for me on the YubiKey test page: https://demo.yubico.com/u2f

Comment 292

[Marcos H. Alano]

(In reply to Kyle from comment #291)
> - 57.0a1 (2017-09-16) (64-bit)
> - Windows 10
> - YubiKey NEO
> 
> I have enabled the following in about:config
> 
> security.webauth.u2f;true
> security.webauth.webauthn;true
> security.webauth.webauthn_enable_softtoken;true
> security.webauth.webauthn_enable_usbtoken;true
> 
> It does *not* work for me on the YubiKey test page:
> https://demo.yubico.com/u2f

Please disable "security.webauth.webauthn_enable_softtoken;true" option and try again.

Comment 293

[Marcos H. Alano]

(In reply to Marcos H. Alano from comment #290)
> I tested on Ubuntu 17.04 and 17.10 using nightly release from the PPA on
> Yubico U2F demo page but doesn't work. I will test again with the latest
> nightly release on Github

Nevermind. I used a fresher Firefox Nightly and worked very well. Just waiting Google to update his systems to allow Firefox.

Version: 57.0a1 (2017-09-16) (64-bit)
OS: Ubuntu 17.04/17.10
Token: Yubikey NEO
Test page: https://demo.yubico.com/u2f

Comment 294

[Kyle]

Setting "security.webauth.webauthn_enable_softtoken;false" made it start working on the Yubico test page. Thanks.

Trying it now with bitwarden password manager and it is not working. The old Firefox addon did.

Relevant code: https://github.com/bitwarden/web/blob/master/src/app/settings/settingsTwoStepU2fController.js#L37

Console just says "listening for key...".

Need to investigate more...

Comment 295

[Iñaki Arenaza]

Works for me too.

* Debian Stretch
* Yubikey Neo
* Sites tested so far:
  * https://demo.yubico.com/u2f
  * Github

Comment 296

[Gerhard Poul]

Successfully tested 57.0a1 (2017-09-16) (64-bit) running on macOS 10.12.6 (16G29) with yubico demo and GitHub.

Comment 297

[Dmitri Smirnov]

Fedora 26 with Firefox Nightly off the official repo.

Github: works,
Yubico test web page works,

Facebook: doesn't work even with spoofed UA (website keeps waiting for the key to be inserted, works fine on previous versions with addon)
Google: doesn't work even with spoofed UA (unable to login with registered U2F key, unable to add new key when already authenticated and in account settings).

Comment 298

[Adrien / Alpha]

I confirm Dimitri's comment on Win10 with latest nightly build.
Yubico test ==> ok
Facebook : not possible to set a key (user-agent based restriction), removed when spoofed but doesn't go further
Google : same as Dimitri

Comment 299

[Brad Hill]

I'll try to take a look at the Facebook implementation this week and remove the UA restriction if I can get it working.

Comment 300

[My1]

@Brad are you from FB so you can remove that restriction? if yes why have a UA based restriction anyway? why not somehow JS-check for the feature rather than just throwing the UA restriction around, this is one of the reason why each browser says mozilla by now.


small sidenote: did anyone else have to change their bugtracker password because it was too short? I even tried 15 characters and it was too short, without even stating how long it needs to be, just "too short", which is kinda annoying.

Comment 301

[Ryan Pollock]

@My1 See Brad's earlier comment in this bug. https://bugzilla.mozilla.org/show_bug.cgi?id=1065729#c264

Great to see this starting to work in Nightly! Thanks.

Comment 302

[Andreas Gnau]

For some other sites to test see:
https://twofactorauth.org/
http://www.dongleauth.info/

Comment 303

[Chris Morgan]

A successful sign request is producing a response that includes `errorCode: 0`; I don’t believe it should be. The u2f.sign() callback argument is of type function(SignResponse or Error), and SignResponse does not include an errorCode member.

I think the waters were muddied by the spec saying that “An error can be detected by testing for a non-zero errorCode key”, and by the presence of the utterly useless ErrorCode.OK = 0.

(Encountered this testing U2F with FastMail—our server validates the structure strictly and was rejecting it because of errorCode’s presence.)

Source: https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20150514/fido-u2f-javascript-api-v1.0-ps-20150514.html, I think that’s the right spec here?

Comment 304

[g.rantila]

It doesn't seem like the current implementation respects the "App ID", or rather "Multi-facet apps". I'm having success with single-facet apps, i.e. when the server protocol+domain name exactly match the "appId" field (e.g. in the register request), but not multi-facet apps. The "appId" is supposed to be able to be a url to a JSON file where you specify multiple subdomain names. Doing this fails Firefox (even if the subdomain is correct) - it feels like Firefox is string-matching the appId with the current web page location, which isn't right.


https://developers.yubico.com/U2F/App_ID.html

Comment 305

[Arnar]

(In reply to Chris Morgan from comment #303)
> A successful sign request is producing a response that includes `errorCode:
> 0`; I don’t believe it should be. The u2f.sign() callback argument is of
> type function(SignResponse or Error), and SignResponse does not include an
> errorCode member.
> 
> I think the waters were muddied by the spec saying that “An error can be
> detected by testing for a non-zero errorCode key”, and by the presence of
> the utterly useless ErrorCode.OK = 0.

Ah you are correct. The intention was to say "check for presence" rather than non-zero. The 0=OK value is a vestige from an older version of the spec where all responses had an errorCode member. Success responses should *not* have an errorCode member.

I'll file a bug to FIDO.

> (Encountered this testing U2F with FastMail—our server validates the
> structure strictly and was rejecting it because of errorCode’s presence.)
> 
> Source:
> https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20150514/fido-u2f-javascript-
> api-v1.0-ps-20150514.html, I think that’s the right spec here?

Comment 306

[Stefan Fleiter (:sfleiter)]

(In reply to g.rantila from comment #304)
> It doesn't seem like the current implementation respects the "App ID", or
> rather "Multi-facet apps". 

This sounds like bug 1244959 which is talking of maybe making this a WONTFIX.

Comment 307

[Brad Hill]

(In reply to g.rantila from comment #304)
> It doesn't seem like the current implementation respects the "App ID", or
> rather "Multi-facet apps". I'm having success with single-facet apps, i.e.
> when the server protocol+domain name exactly match the "appId" field (e.g.
> in the register request), but not multi-facet apps. The "appId" is supposed
> to be able to be a url to a JSON file where you specify multiple subdomain
> names. Doing this fails Firefox (even if the subdomain is correct) - it
> feels like Firefox is string-matching the appId with the current web page
> location, which isn't right.
> 
> 
> https://developers.yubico.com/U2F/App_ID.html

Yep, that seems likely based on https://hg.mozilla.org/mozilla-central/file/tip/dom/u2f/U2F.cpp#l94

This is a blocker for Facebook. We serve the AppID facet list from https://www.facebook.com but have several subdomains and a number of public test tiers the origins of which we expect to work with that registration: https://m.facebook.com, https://www.alpha.facebook.com, etc.

I think I have fixes ready for the other issues ready.  We also weren't correctly handling return of ErrorCode 0 on success as noted in #305, and the proxying as done by the u2f-api.js from https://github.com/google/u2f-ref-code/blob/master/u2f-gae-demo/war/js/u2f-api.js didn't work in our environment because window.u2f is read-only. (not sure how it works on u2fdemo.appspot.com) Skipping the wrapper and passing register/sign calls directly to window.u2f if it exists fixes that.

Comment 308

[Brad Hill]

The WebAuthN behavior of allowing any domain in the same eTLD+1 of the facet origin would also work. (So an AppID at https://www.facebook.com would be valid at *.facebook.com)

Comment 309

[g.rantila]

Brad, "would also work" for who? landing.alpha.facebook.com wouldn't work in your solution, would it?

This bug should be about proper *U2F*, so charlatan hacks to mitigate implementation flaws are a bit irrelevant. People should be able to read *specs* and expect them to work in browsers that *claim* to support the spec. I'm not even fine with the current solution of a half-complete U2F or WebAuthN-rules for single-facet apps (which effectively wouldn't make it "single") even if Mozilla wouldn't claim that Firefox *supports* U2F. Don't take us back 20 years to the nightmare we went through back then with browser support.

I don't understand why there even is a bug 1244959. This should be it. Either it's "U2F" or it's "Mozilla Passkey Feature (TM)".

If people have tested *proper* U2F a few years ago, and built sites with that feature, working fine with Chrome, Firefox now claiming U2F but not working on those sites is *not cool*. You simply don't go change domain names (and all the infrastructure, teams, Ops, DevOps, technologies etc.) because Mozilla.

Hold back (or as an opt-in about:config flag) until proper support. Please.

Comment 310

[Kyle]

Please don't create a half-baked solution.

I have a feeling this is why bitwarden U2F (as reported above) does not work currently since it is using a faceted app id file (https://vault.bitwarden.com/app-id.json).

Comment 311

[Ben Toews]

GitHub publishes a list of trusted facets and it sounds like it is working.

Comment 312

[My1]

@Brad, that might work as a workaround as long as obviusly not axing any part of the appid, aka removing the json path from the URL, but it's a bad Idea nontheless, I mean doing stuff this half-bakedly has led to User Agent-based restrictions and other stuff and is the reason why mozilla is now unnessecarily included in every Damn UA string.

The chaos of which browser can do what the best is plain annoying and just half-heartedly supporting it isnt good imo.

Comment 313

[Mark Banner (:standard8)]

Hi all, please can you move discussion off of this tracking bug and into better locations.

If there are issues with the implementation that you are finding, please file separate bugs that block this one, so that they can be tracked more easily - otherwise issues raised here are likely to be lost in the comments.

This bug already has too many comments, and extra comments are unnecessary noise for those who are tracking this to the finished implementation.

Comment 314

[g.rantila]

Thanks for the work on this feature so far, we're all excited and eager for Firefox to have this, but Mark, this bug and discussion *is* about U2F.

Cherry picking what you *like* from the spec and leaving the rest to separate bugs certainly won't help anybody outside Mozilla, but I understand the inconvenience and will continue in sub-bugs (if at all). I just have something to say which I think belongs here:

If Firefox is shipped with the current *unfinished* U2F, I will block it from https://www.npmjs.com/package/u2f-api and refuse bug reports with a link upstream. That is, here. I'm not interested in discussing broken U2F support in Firefox in *my* bug tracker, which is exactly what would happen otherwise.

You must understand that you can't cherry pick like this, since you'll leave a big mess for everybody else to pick up and have to deal with. Not cool. Please hold back until fully supported, and again, thanks for the effort!

Comment 315

[mark]

Nobody is proposing to ship U2F in an unfinished state.
The whole idea of nightly is that people can test things, and report bugs.
It is very good to see that this is now happening, and that people are reporting these bugs.
Of course these bugs should and will be resolved before the U2F feature is released into stable.
The only thing Mark Banner is proposing is to create sub bugs for all found issues, so they can be properly managed and resolved.

Comment 316

[My1]

sadly to burst your bubble mark, but actually and sadly there is.
https://bugzilla.mozilla.org/show_bug.cgi?id=1244959#c2
he says that he wants to make it a wontfix unless really needed and kicked it to P5, which as far as I read correctly is pretty much a "not intrested".

Comment 317

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Extended, off-topic comments on a bug add noise to the signal. Per, https://bugzilla.mozilla.org/page.cgi?id=restrict_comments_guidelines.html, we've restricted comments on this bug to Mozillians with EDITBUGS permissions. 

This bug has been updated to a meta-bug to track dependencies for this work.

Comment 319

[Jonathan Watt [:jwatt]]

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

Comment 320

[Julien Cristau [:jcristau]]

The 60 relnotes mention WebAuthn (bug 1294514), which I think covers this.

Comment 325

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

Bug 1550625 will finish wiring this up for Android. Implementation in Gecko is complete, and Bug 1539541 enabled FIDO U2F by default in Firefox 67, releasing next week. Except iOS, FIDO U2F support is complete. See https://bugzilla.mozilla.org/show_bug.cgi?id=webauthn-ctap2 for continued future work on FIDO2/CTAP2 support, which for most platforms will be supported via the Rust implementation in-progress in https://github.com/mozilla/authenticator-rs/tree/ctap2