Question about FIDO2 authentication

I’m in the middle of listening to the latest SN episode, and Steve points out that FIDO2 only makes random keys and doesn’t do deterministic keys the way SQRL does. Is this something required of the spec? If you did use deterministic keys with FIDO2, how would anyone know? As long as the generated deterministic key is FIDO compliant and can be used with Webauthn, why does FIDO2 care how the key was generated?

Second question. Steve pointed out that the keys can’t be exported, only synced between devices. Why? Is there something in the spec that forbids this? If I use a password manager such as Bitwarden or Lastpass that has FIDO2/Webauthn support enabled (I know none of them do right now), I should be able to export all those keys and import them into something else, unless the app won’t let me.

And one last thing, I believe the FIDO2 spec requires either a hardware key OR biometrics. You can’t just store your keys on a device without biometrics. That sounds to me like all those high-end Windows desktop gaming rigs are going to be out of luck, since I’ve never seen one with a fingerprint reader. My MacBook Pro will be fine, but my Intel Mac mini (which can’t use the new Apple Keyboard with TouchID) will be SOL for FIDO2. Yes, I know you can use your phone to authenticate to a website, but not an ideal solution. I prefer to leave my phone in my pocket and use the computer I am working to login to web sites.

1 Like

In a manner of speaking, yes. FIDO2 is based on U2F which became FIDO1. In FIDO1 keys there are no storage, and the trick that Steve used to generate deterministic keys was a SQRL innovation, so was unknown to the designers of U2F. Accordingly, they have one secret key baked into the key, which is immutable and “impossible” to extract. (In that successful extraction would be an attack, to be prevented.) They use this one key to encrypt the randomly generated key, and ship that encrypted block off to the site they just registered with.

That’s right, the site stores the public key in the clear, and the corresponding private key secured by a secret key in the FIDO device. This means if the site loses your data (as in disk crash) there is NO way for you to recover the credential you were using. (Which is probably fine if they lost it too, but it’s also a little strange when compared to any other prior authentication system.)

So, while you could use a deterministic key, there would be NO value in doing so, because following the spec, whatever key you use needs to be exported to the site anyway. There would be no value or use of making it deterministic because you can never be like SQRL and have FULL control of your private keys.

2 Likes

I just posted my own thoughts in the other thread! :smile:

In addition to the excellent answer @PHolder gave, I think the problem is not that they can’t be exported, but that they are not mandated by spec to be exportable. That means that each implementer gets to choose whether it happens and how painful to make it.

It’s sort of the worst of both worlds to have an industry consortium come up with a standard that is only selectively interoperable, since the biggest draw of standards bodies (wide interoperability) is not met while the biggest downsides (regulatory/industry capture) are. /shrug

I’m also hoping that Bitwarden will save me. But I also am not sure to what extent these devices will empower Bitwarden to act as a first-party citizen, or if there will be additional friction in the process that would serve as an anticompetitive edge for the incumbents’ implementations.

As an aside, I searched the website and found that Red Hat is also a member of the FIDO alliance. I’m hoping that this means a similar sign-in experience comes to the Linux desktop that powers my household.

1 Like

So, FIDO1 uses the same private key across all sites, which is baked in your security key. But FIDO2 does not use one secret key, but instead uses a unique private key per site?

Well, I’m guessing a lot here, because while I read the FIDO1 spec, I haven’t read the FIDO2 specs. But what I am led to believe, by someone who had actually implemented some of FIDO2, is that the keys have storage for up to 25 “usernames” for sites to be completely reliant on the storage in the FIDO2 security device, the user has no need to enter username nor password. As far as I understand it, that is just used to look up your record, and then basically FIDO1 protocols now apply. So random keys looked up by a locally stored value. (For up to 25 sites.)

Fast Identity Online? I going have look this up I’m lost.

That’s the part that is confusing me. Yubikey people think that you’ll be able to use the built in Webauthn to create an unlimited number of logins. But it’s unclear if that’s how FIDO1 works, or if FIDO2 is the same way. When you look up FIDO2 on Yubikey’s website, they just go on and on about FIDO2 being an extension of FIDO U2F. They don’t talk about the 25 key llimit and whether that’s a FIDO2 thing, or only for resident keys.

I own 3 Yubikeys and I like the IDEA of them. My problem with them is that they’re incredibly memory constrained. They can hold only 25 FIDO2 resident keys. And they can only hold 40 TOTP codes.

I like the idea of having my TOTP codes on the Yubikey, because I can access them anywhere. I cn walk up to any PC, tablet or phone, install the Yubico Authenticator app, tap your key and you can get a 2FA code. Then you walk away and that device does not have access to your TOTP codes any more.

If FIDO2 passwordless logins take off (which I hope they do), then 25 slots is really not going to be enought.

I found one discussion thread that said FIDO2 U2F doesn’t use any space on the device. But FIDO2 Passwordless does require one of the 25 resident slots.

This thing hasn’t even rolled out yet, and I’m already confused. I feel like SQRL is definitely a better solution.

At some point this will turn into a support nightmare that no one is going to want to deal with.

FIDO 1 was a 2FA token based system. You needed the username and password, then it would ask for the token to confirm your identity, much like the Yubikey (without U2F).

FIDO 2 allows the replacement of the password, if you have the Yubikey with FIDO2 (or other compatible key), you enter your username at the site and it asks you to activate your FIDO2 key. (It could possibly work without username, but at present, you enter username and password or use FIDO2, so it needs the username to check whether it needs to ask for a password or accept a FIDO2 key; I assume, in theory, you could click on FIDO2 authentication on the first screen, but that would be too confusing, until it is a general requirement and passwords on sites are phased out?

I use full passwordless logon for my Microsoft account already and use FIDO2 for Google and a few others.

This is not strictly true. They brought it to market this way, but there is no reason why it couldn’t be used as a single factor authenticator. You would still need the username to look up the account info, but there is nothing in the protocol that cares if your have any other factors.

1 Like

The question I am trying to get answered is does FIDO2 Passwordless login require the use of one of those 25 resident key slots in a Yubikey, or if it can use the private key baked into the Yubikey? If each site you visit requires a unique private key, then that will fill up 25 slots very quickly. If you can just use the built in key, then you can use your Yubikey with an unlimited number of sites.

From what I read, the software based implementaion that Apple, Google, Microsoft and FIDO are proposing will generate a unique private key for each site. But reading through the FIDO website and Yubico’s website, I can’t find out if that’s REQUIRED, or if the existing FIDO U2F mechanism that just uses the key baked into the device will work.

The other issue is, when plugins become available for popular forums and CMS systems, will they allow you to set up more than one private key? Software based FIDO2 is supposed to sync across devices, so you can use your keys on an iPhone, and iPad and your Mac. So, these plugins may work with a Yubikey, but they may not offer to store more than one private key. That will turn into a problem.

I really hope that they release a Yubikey 6 with a LOT more storage. If I can’t store a couple of hundred TOTP codes and a couple hundred FIDO2 private keys, then it doesn’t have enough memory.

The built in secret key is likely a symmetric AES256 key. It would not be usable for public key cryptography. As that is an implementation detail, it’s impossible to actually know what that key is or how it is used, as it’s not actually defined, and does not need to be defined, for the protocol to work. The protocol simply requires that the data exported, for storage on the site, is secure in a way that when it is later returned to the FIDO security device, it can securely extract it and use it to complete the authentication protocol.

So, does this mean that a Yubikey would be limited to 25 FIDO2 passwordless sites, or that it can do unlimited sites.

I opened a support quesion with Yubikey. but since they pandemic started they’re super slow to respond. I think I have a support request open from 2021 that hasn’t gotten a response.

Well, I have yet to read the FIDO2 specs, because the alliance writes them in the least understandable way possible and I just don’t have the energy right now. But my understanding is that the 25 slots are for the equivalent of usernames. Basically, I believe, FIDO2 is just FIDO1 (which is just U2F) plus 25 slots for special logins where you don’t need to first supply a user name.

In essence you can choose sites (once support is available, if ever) where you just go to the site, and wait for it to query if your browser is FIDO2 (aka WebAuthn) enabled. If it is, it will query if the browser already knows the username. If it does (it’s one of the 25 you’ve chose to store) then it will proceed to requesting you do the necessary step (depending on OS and browser and FIDO device that might be show your face, press a button, read your fingerprint, etc.) to complete the authentication.

For any other site, you’ll need to first identify yourself in some way (provide a username or email.) From that point, it can look up your record in the site’s authentication database, and then proceed as normal.

In the background it is still doing U2F (aka FIDO1). Which means the site looks up a secured blob, sends it to your browser, which loads it into your FIDO security device. The device uses some proprietary means to decode the blob, verify it is one it that belongs to it, and then uses it to prove it can provide a valid challenge that can be decoded by the public key that was also stored at the same time as the proprietary private blob.

In essence, registration is “here, store this blob and public key, and if the user authorized, give me my record number so I can be username-less.” On return the process is “I have a record number from last time (or here’s my username), please send me the blob you said would store for me. Okay that blob is valid, use my public key to verify that this challenge proves I’m the same device that previously registered.”

I tried to read through some of it yesterday and it was NOT very well written. There’s a FAQ on Yubikey’s website that says the 25 slots are for resident private keys.

FIDO2 is an extension of FIDO1 U2F, allowing you to use FIDO secret keys as your only login. But FIDO1 requires you to use a security key. FIDO2 relaxes that requirement and allows any device with either PIN/password or biometric authentication to be used to store the private key.

I suspect it’s going to be an either/or thing. You can use a Yubikley and it’s hardcoded FIDO secret key, or you can use a phone/tablet/computer and let it generate a unique secret key.

The big queston is going to be, as sites roll this out, will they allow you to have more than one secret key. Hopefully Yubico will respond to my ticket soon.

Apparently you’re not used to reading RFCs? You need to be exceedingly explicit and clear so that someone could use the documentation to produce a working implementation from the documentation. That normally includes things like test vectors and other things they do not provide. (Last time I looked anyway.) Their best instruction is “look at the Chromium source for an example implementation,” which, to me, means they wrote the documentation BEFORE they had a working implementation, and were too lazy to go back and add the necessary details to help someone else do an implementation.

Great conversation you guys. I think this is an important topic and well worth understanding. I wish I did.

Sorry I meant NOT very well written.

Keep reading this thread. Eventually enough people will chime in that it will make sense eventually.

From WebAuthn Developer Guide

1 Like

From Resident Keys

This doesn’t REALLY explain how the site knows who you are. If every user of the site has their own user.id property then how does it know which one is yours when you arrive at the site?

It continues on with this, which is a little wishy-washy to me: