Using Fido U2F or similar as primary authentication method?

Question

I've been wondering about this for a while, but couldn't find much on the web, so I hope that someone could point me in the right direction for better understanding about this topic.

Would it be viable / safe to use something like a Fido U2F device as primary authentication method (mostly thinking about web apps here, but possibly not limited to)?

I've been using client-side SSL certificates in the past for this, but of course that requires client configuration; I know the same should be possible using a standard smartcard, but of course most devices nowadays lack a smartcard reader. The Fido keys look like the perfect form factor to carry around a private key pair without need for a reader; for mobile devices you could just use NFC (as newer yubikey do) or a built-in "on the go" adapter.

Now, I understand the problem of the key being stolen, but I imagine that could be solved / mitigated by using some PIN to unlock the key, as with most smartcards. As an additional security measure, websites could ask for a password as "2nd-factor". That would mean of course having to remember a password, but just for those really crytical systems you absolutely want to be well protected.

In my hope, something like this could help greatly improving both on the security point of view and lowering the login friction (for users) and complexity (for implementers) as well.

Now, is there any major issue / roadblock in going this way? It almost sounds like browsers would already be able to use a smartcard for auth, the only thing missing would be to develop an actual device (assuming there is no way to add a PIN to Fido devices)..

Answer 1

Indeed! I use/build/deploy both standard smart card PKI solutions (SSL client certificate, applets, browser plugin, middleware...) and FIDO U2F simplified PKI solutions and FIDO U2F works great even as a primary authentication method.

It can be used as a primary authentication through a shared login url page with username and FIDO U2F or through a by-user-unique login url (to identify username without even asking) with FIDO U2F. Another non-standard use case but easy solution if you only have to deal with a very few users: you can even skip the "asking for a username part" (server only need to send every known key handles to the device to find the right one).

About adding PIN protection, we are starting to see products with local PIN entry protection like the onlykey (https://crp.to/p/)

You can even develop your own FIDO U2F API compatible solution with enhanced features to add PIN protection, shared identity, simplified encryption... I am one of the few "mad dogs" working on such solutions.

Note/reminder : FIDO U2F works on Chrome on Windows, Linux, OSX, Android. Firefox built-in support should be available in a few weeks. There are already FIDO U2F USB security keys, NFC Cards/keys and soon there will be Bluetooth Low Energy (BLE) devices.

Answer 2

While U2F as only factor is only good in environments where a possession proof is enough (like those RFID card doors) and using U2F as first factor after the user name actually being (in my opinion) a decent way to stop others from even trying out passwords unless we have a resonable assumption that the person trying to sign in MIGHT BE who he is saying he is (which is actually something I am trying out in some hobby projects), there are some pretty awesome news.

The U2F Api in browsers is being replaced with Webauthn, which is an API which not only encompasses U2F but also more/different types of authentication possible for web.

especially important to note here is the Successor to U2F, Fido2, which is as the name says, made by the same FIDO Alliance that made U2F a thing.

Webauthn adds 2 important new things that Fido2 also brings along:

1. User Verification, which just means you have to enter a "PIN" which is more like a "local unlock password" (as it is up to 255 unicode chars) or go biometric (like a fingerprint check) depending on your device if you want to authenticate somewhere that doesnt actively discourage using user verification. simply said Webauthn has 3 options for user auth a website can ask for

   1. preferred, the default, which basically means, if the user can be verified, please do so, but if it cannot (either due to no data for that, or we are dealing with a device that has no verification like one with just U2F), just verify the presence of the user (push the button)

   2. required, if a device can do verification, but has no data to do so (pin/biometry etc) ask the user to create such data, and if the device cannot do it, just reject it.

   3. discouraged, which just tries to bypass the validation altogether to reduce friction, which is useful in second or possesion-only-factor scenarios.

2. Resident Keys. 1 "Problem" U2F and the "normal" mode of webauthn has is that it has to be known who we want to authenticate so we can bring along the right registration data sets (mostly the keyhandles) with the challenge because storage is limited, usually some PRNG/KDF tricks are used to not actually store the private keys or keypairs on the device itself but just the internal secret, and the website gets a keyhandle to store which is related by some algorithm with the actual keypair, which allows literally infinite key pairs for one device since every site has to store the unique data needed to create the key using the static secret of the device.

   Resident Keys are literally what the name says, keys that reside on the Device. As Storage is not limitless, and secure storage even more so, they are limited. The Yubikey 5 Series allows 25 resident keys, the solo 50. as far as I am aware they also always require Verification so with resident keys you literally just click a button on the website which issues a challenge to the device which asks for your pin, if you have multiple resident keys for a website the browser will ask which you use (as of writing this this is Edge on Windows 10 only) and you are signed in and never entered anything into the website, no username, no password that gets transmitted to the website, just the verification for your device.

   but while they seem pretty awesome, there was one HUGE oversight by the Fido Alliance on those resident keys. You can only delete resident keys by resetting the entire device, so if you fill your resident slots up and have some keys you no longer use/want, you either have to deal with it or reset the device and re-register it everywhere.

Quick note on my wording: I call the physical devices which offer these things just as "devices" because while they are commonly called "Security Keys", I wanted to have a clear distinction between when I am talking about the device, or the cryptographic keys, so "Key" always refers to a cryptographic key.