7 ms·

Passwordless authentication with FIDO2–beyond just the web

103 points by pabs3 4y ago

taeric 4y ago
".. the biggest advantage of FIDO2 security keys is that they are cheaper and more user-friendly.". Not wrong, but also overselling how user friendly the new keys are. Somewhat amusingly, the yubikeys also support storing a gpg key. So, most of the old stuff still works with them.
- wkat4242 4y ago
  Yeah I use the GPG functionality for a lot of stuff. SSH keys, file encryption, my password manager (which is zx2c4's pass, basically using GPG file encryption). The software toolchain is anything but friendly indeed. On Android it's the easiest with Openkeychain but in Linux and Windows it's hard to get gpg running with CCID key support (USB smartcard which is what the Yubikey emulates). It's also pretty buggy, gpg's scdaemon tends to crash a lot. Technically I could move some of this stuff over to FIDO2. Like SSH logins. But I don't see the point until I can move all my usecases over, and older SSH servers don't support it, like the ones in my HP iLO boxes which I can't update. So I'd still have to keep 2 separate systems side by side which isn't worth it. So on I go but yeah it isn't for everyone. FIDO2 will make this a lot better. Eventually. Right now Firefox doesn't even support passwordless FIDO2 logins (CTAP2) on Linux or Mac, only on Windows... This really keeps me from implementing it because I use Firefox on FreeBSD and Linux. I really don't get why Mozilla doesn't prioritize this.
  - pezezin 4y ago
    Have you tried the PIV mode for SSH? I found it much easier to setup than GPG mode, and it works flawlessly on Linux.
    - wkat4242 4y ago
      I have yes, but I find the PIV management tools for the card itself very poor. Also, I use PIV for work, so this way I can separate personal and work use and still use the same yubikey for both.
  - vladvasiliu 4y ago
    I haven't tried using the GPG mode on mobile, but I've had absolutely 0 issues with it on Linux. Just followed the arch wiki setup and this random guide I found: https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide. I use it daily to ssh into hosts and sign git commits. On Windows, it's a bit more involved, of course, especially for SSH. I seem to remember that I did find at one point some hack which allowed ssh to use the GPG agent. Since I only rarely use Windows, I didn't care enough to test it through. Code signing seems to work well enough. SmartCard emulation also works well enough, but it does seem to conflict with some other mode, either U2F or GPG, can't remember which. You have to un/replug the key to switch modes. I am also quite... surprised at Firefox's apparent lack of priority for supporting CTAP2. I've seen there are long-open bugs, but not that much interest. My understanding is that on macos and windows, it delegates the user verification to the os, and on linux there isn't anything for that. FWIW, chrome seems fine with implementing their own.
    - wkat4242 4y ago
      Thanks for the link! The main problem I have is that gpg-agent won't start in ssh-agent mode automatically. I noticed on Ubuntu that there's some scripts that check if this directive is present in ~/.gpg/gnupg-agent.conf and then start it accordingly (and not load gnome-keychain) but this is not working correctly. I spent ages messing around to get it to load. These days I use FreeBSD with KDE and it was a bit easier to get it to work. But I still have the scdaemon crashes a lot. But yeah I really wish they would finally fix CTAP2 on Linux. I think the problem is a bit chicken and egg / there's not many services actually supporting it yet. Microsoft 365 is the only one I use that has it. And there it's in 'preview' so my work doesn't allow it, on my personal instance I do have it enabled though.
      - vladvasiliu 4y ago
        Passwordless U2F is no longer in preview on Microsoft 365, at least when I look at the config through the Azure AD interface. However, the situation is actually worse than that on the MS front. Because it actually requires user verification even when used as a second factor, you cannot use such a token at all with MS's ecosystem. Which basically means that if you use Firefox on Linux, you're stuck with less secure second factors. Paradoxically, MS Edge on Linux doesn't support CTAP2, either, although it's based on Chromium, which works OK.
- sebazzz 4y ago
  The blue Yubikey Security Key only has WebAuthn (FIDO). The 5 series does have GPG.
  - taeric 4y ago
    Ah, great point. I forgot they have basic FIDO only keys. I have mostly the NFC and micro ones. I also picked up the Google Titan keys back when, but since they are FIDO only... it greatly limited my use of them.
Proven 4y ago
[dead]
donatj 4y ago
Can someone explain to me, what is the recovery process if I lose my phone when all my accounts are passkeyed? Just create new accounts on everything, full new digital life? A couple years ago I broke my phone and was unable to access my gmail account thanks to 2FA. This seems like that nightmare scenario on steroids. Roughly half of new phones are purchased because the previous one was broken.
- TacticalCoder 4y ago
  > This seems like that nightmare scenario on steroids. I'm an oddball in that I'm using a U2F (for SSH) / webauthn (Google, domain name registrar, etc.) device on which the master key can be reset. It's a tradeoff: I now better make sure nobody steals my "paper seed" in the real world and I better make sure I don't lose it [1]. But in exchange should I lose/break/someone steal my device (which is protected by a PIN btw), I can initialize a new one. Now there are schemes (like m out of n) where you can distribute, say, part of the paper seed to several siblings/family members/friends or store a part in the safe at the bank, etc. Making it highly unlikely you'll ever lose access to your master paper seed (which is a list of 12, 18 or 24 words out of a vocabulary of 2048 words). As a bonus the device has a tiny screen which tells you if you're registering to a new service or authenticating and tells you the name (if it's a known service, hardcoded in the device) and/or ID of the service you're authenticating too. It is protected by a PIN. It has a plausible deniability feature where you can unlock a fake master key. And I can buy as many of them as I want and initialize them all with the same seed and then hand them to family members/friends/put one in the safe at the bank. They're all protected by a PIN anyway. So if my house burns down, I'm not sorry out of luck: I can be back in business immediately (i.e. without needing to order one, wait for it to arrive, then find back my paper seed and reinitialize it). Originally it's a cryptocurrency hardware device but I don't care about that. The CTO of that company was part of the original FIDO alliance. The device I use is a Ledger Nano S (cost $79 bucks or so) and I load one "nano app" on it, the "U2F" one (works for SSH and works for webauthn). Now I don't know exactly what's going to happen now that Google, Microsoft and Apple are teaming up to embrace FIDO2 with their new "passkeys" standard (which AFAIU ain't 100% finalized yet). From the testing I did it looks like Google removed the "counter" verification from their site, which allowed to detect cloned security keys. They used to check for clones, but don't anymore (or at least don't warn the user anymore). I'm nearly sure this removal of clone detection is related to the upcoming "passkeys" thinggy. I don't know if the older U2F devices (which are compatible with Webauthn as Webauthn is only a server side protocol change) shall still be usable once the "passkeys" is finalized: if anybody has infos on this, I'm all ears. Meanwhile SSH since 8.2 can use all U2F keys (including the Ledger Nano S) and that is a godsend already. [1] although if I realize I lost my "paper seed" and I still happen to have my FIDO2 device (or any cloned one I prepared in advance), I can enroll a new device so I'm not totally screwed. And I'll had that many people using a security key that cannot be clone do still use "backup codes" they write down on a piece of paper, which is not safer than writing down a list of words allowing to reinitialize a FIDO2 device.
timwis 4y ago
Can someone explain why people seem to be so happy with hardware tokens that they're okay with doing away with a password entirely? Doesn't that bring us back down to single factor authentication (now just 'something you have')? Or is the argument that if the majority of users only have a single factor anyway, hardware tokens are a better single factor than passwords, and that ideally everyone would still have two factors?
- panny 4y ago
  It depends on how you're using it, but the hardware token generally requires a pin for most operations. I think the real argument is that hardware tokens absolve the web host/service of responsiblity for passwords. With tokens I'm just presenting the challenge given a public key. Nobody can hack all the tokens at once like they can a database full of passwords.
- lloeki 4y ago
  With devices that have biometric validation it becomes something you have (unextractable private key in secure enclave in laptop, phone, or hardware token) + { something you are (face or fingerprint that unlocks secure enclave) || something you know (pin or password that unlocks secure enclave) } Of course recovery codes are a single factor, so to have it be 2FA still they should not be memorised (to keep them as something you have, not something you know) and be locked away in a way that adds a second factor, e.g in a safe locked by biometric or gated by an id check (bank, notary office) for something you are, or a pin/code/password for something you know. Sounds cumbersome? Maybe, maybe not. It all depends on your trust model + threat model. Maybe a bank is too much and a trusted friend or neighbour is fine for "id check", maybe not. The less you trust the less options you have for recovery. As an example: What if one dies? Is there a recovery procedure? Does it entail someone mentioned in a (paper or digital) will having a death certificate at hand? Then one has to trust the designated person not to fake a death certificate, and so on and so forth.
- michaelt 4y ago
  There is a standardisation process with multiple stakeholders. Some stakeholders want hardware devices that are secure even if the OS has been completely compromised - even if they have to trade off usability and price to achieve it. Other stakeholders think iPhone biometrics are pretty great, and if you've logged in with full credentials and indicated indicate the phone is trusted, going forward the combination of recognised phone + biometrics is good enough, even if it doesn't secure against a compromised OS. And in a spirit of standardisation and vendor independence, if iphone face recognition is good enough, why shouldn't the face recognition on a phone from Honest Abraham's Used Cars And Android Phones also be good enough? It is the latter group of stakeholders that are currently ascendant.
sim7c00 4y ago
You can rely on individuals doing sane things, but you can never rely on 'everyone' to do sane things. Hence recovery options exist, and those always cause security problems. I think a really amazing application for this technology is in places where people are unable or face challenges to manually passwords. For example due to equipment such as gloves, or extreme weather conditions etc. or even disabilities... - it's a good secure way and slotting in a device in a port can sometimes be much quicker and easier than taking off equipment and entering passwords. Furthermore, a physical device can be easily destroyed if it needs to be. If its in your brain... you can't destroy your brain and someone can always get to it... Extremely stressful conditions can also make it hard to enter or even remember passwords... Lastly, a robot or even flying drones can be used to slot in a key to a device. entering some code on a keypad would be more of a challenge in such cases. radioactive, chemical or gas leaks and other hazardous circumstances might prevent an operator from entering a password... I think technologies like this should first aim to be implemented in places where to original methods we use aren't applicable, or face challenges. Once those areas are covered, it could be considered to be pushed to more mainstream applications if indeed it is found suitable and understandable, and people have had time in real implementations and operations to iron out the creases that 'regular people' will definitely trip over. Also, having it applied in certain fields might help to convince people it's actually more practical, and not prone to account loss as the default sentiment always seems to be. in short: Like with a lot of technology it should a) first find a place where it's really urgently needed, and has obvious benefits, and little downsides. b) through that, earn trust of potential consumers in order to apply it more broadly. It might sound a bit off the ball, as essentially the aim is to increase security for all people in interacting with services / devices / data etc., but you need to start somewhere more practical rather than trying to immediately come up with that golden solution which will put a lot of people out of business. such solutions ,even when achieved, are rarely implemented in the real world or face adoption issues anyhow. (due to 'harsh competition' usually... )
taeric 4y ago
Would love if my security token could unlock my house/car. Would go a long way for me to convince others that keeping one of these keys is meaningful. As it is, the ones that go on a keychain are basically useless for the vast majority of people. Even folks that will be using a key often, are best off getting the micro that you leave in the device.
- deleted 4y ago
  [deleted]
juliangmp 4y ago
While I'm glad to see this be dome with the W3C (that way it can actually be standardized and used by more than just two platforms), I find it kind of odd that something like the Secure Remote Password protocol (SRP) hasn't seen much use. Or at least I haven't seen it, correct me if I'm wrong. That way the password is never known to the server and we also don't have to rely on hardware keys. Personally I don't know anyone using hardware keys, they're just annoying to use...
throwing_away 4y ago
> The user again proves possession of the authenticator and the device generates a response by signing the challenge with its private key. This sounds very similar to how hardware wallets work. I know some wallets support FIDO2, but I wonder if FIDO2 devices like yubikeys could also be used as hardware wallets. There are probably UX reasons why this isn't a good idea, but I wonder if the math would work.

103 points by pabs3 4y ago

".. the biggest advantage of FIDO2 security keys is that they are cheaper and more user-friendly.". Not wrong, but also overselling how user friendly the new keys are. Somewhat amusingly, the yubikeys also support storing a gpg key. So, most of the old stuff still works with them.

wkat4242 4y ago
Yeah I use the GPG functionality for a lot of stuff. SSH keys, file encryption, my password manager (which is zx2c4's pass, basically using GPG file encryption). The software toolchain is anything but friendly indeed. On Android it's the easiest with Openkeychain but in Linux and Windows it's hard to get gpg running with CCID key support (USB smartcard which is what the Yubikey emulates). It's also pretty buggy, gpg's scdaemon tends to crash a lot. Technically I could move some of this stuff over to FIDO2. Like SSH logins. But I don't see the point until I can move all my usecases over, and older SSH servers don't support it, like the ones in my HP iLO boxes which I can't update. So I'd still have to keep 2 separate systems side by side which isn't worth it. So on I go but yeah it isn't for everyone. FIDO2 will make this a lot better. Eventually. Right now Firefox doesn't even support passwordless FIDO2 logins (CTAP2) on Linux or Mac, only on Windows... This really keeps me from implementing it because I use Firefox on FreeBSD and Linux. I really don't get why Mozilla doesn't prioritize this.
- pezezin 4y ago
  Have you tried the PIV mode for SSH? I found it much easier to setup than GPG mode, and it works flawlessly on Linux.
  - wkat4242 4y ago
    I have yes, but I find the PIV management tools for the card itself very poor. Also, I use PIV for work, so this way I can separate personal and work use and still use the same yubikey for both.
- vladvasiliu 4y ago
  I haven't tried using the GPG mode on mobile, but I've had absolutely 0 issues with it on Linux. Just followed the arch wiki setup and this random guide I found: https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide. I use it daily to ssh into hosts and sign git commits. On Windows, it's a bit more involved, of course, especially for SSH. I seem to remember that I did find at one point some hack which allowed ssh to use the GPG agent. Since I only rarely use Windows, I didn't care enough to test it through. Code signing seems to work well enough. SmartCard emulation also works well enough, but it does seem to conflict with some other mode, either U2F or GPG, can't remember which. You have to un/replug the key to switch modes. I am also quite... surprised at Firefox's apparent lack of priority for supporting CTAP2. I've seen there are long-open bugs, but not that much interest. My understanding is that on macos and windows, it delegates the user verification to the os, and on linux there isn't anything for that. FWIW, chrome seems fine with implementing their own.
  - wkat4242 4y ago
    Thanks for the link! The main problem I have is that gpg-agent won't start in ssh-agent mode automatically. I noticed on Ubuntu that there's some scripts that check if this directive is present in ~/.gpg/gnupg-agent.conf and then start it accordingly (and not load gnome-keychain) but this is not working correctly. I spent ages messing around to get it to load. These days I use FreeBSD with KDE and it was a bit easier to get it to work. But I still have the scdaemon crashes a lot. But yeah I really wish they would finally fix CTAP2 on Linux. I think the problem is a bit chicken and egg / there's not many services actually supporting it yet. Microsoft 365 is the only one I use that has it. And there it's in 'preview' so my work doesn't allow it, on my personal instance I do have it enabled though.
    - vladvasiliu 4y ago
      Passwordless U2F is no longer in preview on Microsoft 365, at least when I look at the config through the Azure AD interface. However, the situation is actually worse than that on the MS front. Because it actually requires user verification even when used as a second factor, you cannot use such a token at all with MS's ecosystem. Which basically means that if you use Firefox on Linux, you're stuck with less secure second factors. Paradoxically, MS Edge on Linux doesn't support CTAP2, either, although it's based on Chromium, which works OK.
sebazzz 4y ago
The blue Yubikey Security Key only has WebAuthn (FIDO). The 5 series does have GPG.
- taeric 4y ago
  Ah, great point. I forgot they have basic FIDO only keys. I have mostly the NFC and micro ones. I also picked up the Google Titan keys back when, but since they are FIDO only... it greatly limited my use of them.

Proven 4y ago

[dead]

donatj 4y ago

Can someone explain to me, what is the recovery process if I lose my phone when all my accounts are passkeyed? Just create new accounts on everything, full new digital life? A couple years ago I broke my phone and was unable to access my gmail account thanks to 2FA. This seems like that nightmare scenario on steroids. Roughly half of new phones are purchased because the previous one was broken.

TacticalCoder 4y ago
> This seems like that nightmare scenario on steroids. I'm an oddball in that I'm using a U2F (for SSH) / webauthn (Google, domain name registrar, etc.) device on which the master key can be reset. It's a tradeoff: I now better make sure nobody steals my "paper seed" in the real world and I better make sure I don't lose it [1]. But in exchange should I lose/break/someone steal my device (which is protected by a PIN btw), I can initialize a new one. Now there are schemes (like m out of n) where you can distribute, say, part of the paper seed to several siblings/family members/friends or store a part in the safe at the bank, etc. Making it highly unlikely you'll ever lose access to your master paper seed (which is a list of 12, 18 or 24 words out of a vocabulary of 2048 words). As a bonus the device has a tiny screen which tells you if you're registering to a new service or authenticating and tells you the name (if it's a known service, hardcoded in the device) and/or ID of the service you're authenticating too. It is protected by a PIN. It has a plausible deniability feature where you can unlock a fake master key. And I can buy as many of them as I want and initialize them all with the same seed and then hand them to family members/friends/put one in the safe at the bank. They're all protected by a PIN anyway. So if my house burns down, I'm not sorry out of luck: I can be back in business immediately (i.e. without needing to order one, wait for it to arrive, then find back my paper seed and reinitialize it). Originally it's a cryptocurrency hardware device but I don't care about that. The CTO of that company was part of the original FIDO alliance. The device I use is a Ledger Nano S (cost $79 bucks or so) and I load one "nano app" on it, the "U2F" one (works for SSH and works for webauthn). Now I don't know exactly what's going to happen now that Google, Microsoft and Apple are teaming up to embrace FIDO2 with their new "passkeys" standard (which AFAIU ain't 100% finalized yet). From the testing I did it looks like Google removed the "counter" verification from their site, which allowed to detect cloned security keys. They used to check for clones, but don't anymore (or at least don't warn the user anymore). I'm nearly sure this removal of clone detection is related to the upcoming "passkeys" thinggy. I don't know if the older U2F devices (which are compatible with Webauthn as Webauthn is only a server side protocol change) shall still be usable once the "passkeys" is finalized: if anybody has infos on this, I'm all ears. Meanwhile SSH since 8.2 can use all U2F keys (including the Ledger Nano S) and that is a godsend already. [1] although if I realize I lost my "paper seed" and I still happen to have my FIDO2 device (or any cloned one I prepared in advance), I can enroll a new device so I'm not totally screwed. And I'll had that many people using a security key that cannot be clone do still use "backup codes" they write down on a piece of paper, which is not safer than writing down a list of words allowing to reinitialize a FIDO2 device.

timwis 4y ago

Can someone explain why people seem to be so happy with hardware tokens that they're okay with doing away with a password entirely? Doesn't that bring us back down to single factor authentication (now just 'something you have')? Or is the argument that if the majority of users only have a single factor anyway, hardware tokens are a better single factor than passwords, and that ideally everyone would still have two factors?

panny 4y ago
It depends on how you're using it, but the hardware token generally requires a pin for most operations. I think the real argument is that hardware tokens absolve the web host/service of responsiblity for passwords. With tokens I'm just presenting the challenge given a public key. Nobody can hack all the tokens at once like they can a database full of passwords.
lloeki 4y ago
With devices that have biometric validation it becomes something you have (unextractable private key in secure enclave in laptop, phone, or hardware token) + { something you are (face or fingerprint that unlocks secure enclave) || something you know (pin or password that unlocks secure enclave) } Of course recovery codes are a single factor, so to have it be 2FA still they should not be memorised (to keep them as something you have, not something you know) and be locked away in a way that adds a second factor, e.g in a safe locked by biometric or gated by an id check (bank, notary office) for something you are, or a pin/code/password for something you know. Sounds cumbersome? Maybe, maybe not. It all depends on your trust model + threat model. Maybe a bank is too much and a trusted friend or neighbour is fine for "id check", maybe not. The less you trust the less options you have for recovery. As an example: What if one dies? Is there a recovery procedure? Does it entail someone mentioned in a (paper or digital) will having a death certificate at hand? Then one has to trust the designated person not to fake a death certificate, and so on and so forth.
michaelt 4y ago
There is a standardisation process with multiple stakeholders. Some stakeholders want hardware devices that are secure even if the OS has been completely compromised - even if they have to trade off usability and price to achieve it. Other stakeholders think iPhone biometrics are pretty great, and if you've logged in with full credentials and indicated indicate the phone is trusted, going forward the combination of recognised phone + biometrics is good enough, even if it doesn't secure against a compromised OS. And in a spirit of standardisation and vendor independence, if iphone face recognition is good enough, why shouldn't the face recognition on a phone from Honest Abraham's Used Cars And Android Phones also be good enough? It is the latter group of stakeholders that are currently ascendant.

sim7c00 4y ago

You can rely on individuals doing sane things, but you can never rely on 'everyone' to do sane things. Hence recovery options exist, and those always cause security problems. I think a really amazing application for this technology is in places where people are unable or face challenges to manually passwords. For example due to equipment such as gloves, or extreme weather conditions etc. or even disabilities... - it's a good secure way and slotting in a device in a port can sometimes be much quicker and easier than taking off equipment and entering passwords. Furthermore, a physical device can be easily destroyed if it needs to be. If its in your brain... you can't destroy your brain and someone can always get to it... Extremely stressful conditions can also make it hard to enter or even remember passwords... Lastly, a robot or even flying drones can be used to slot in a key to a device. entering some code on a keypad would be more of a challenge in such cases. radioactive, chemical or gas leaks and other hazardous circumstances might prevent an operator from entering a password... I think technologies like this should first aim to be implemented in places where to original methods we use aren't applicable, or face challenges. Once those areas are covered, it could be considered to be pushed to more mainstream applications if indeed it is found suitable and understandable, and people have had time in real implementations and operations to iron out the creases that 'regular people' will definitely trip over. Also, having it applied in certain fields might help to convince people it's actually more practical, and not prone to account loss as the default sentiment always seems to be. in short: Like with a lot of technology it should a) first find a place where it's really urgently needed, and has obvious benefits, and little downsides. b) through that, earn trust of potential consumers in order to apply it more broadly. It might sound a bit off the ball, as essentially the aim is to increase security for all people in interacting with services / devices / data etc., but you need to start somewhere more practical rather than trying to immediately come up with that golden solution which will put a lot of people out of business. such solutions ,even when achieved, are rarely implemented in the real world or face adoption issues anyhow. (due to 'harsh competition' usually... )

taeric 4y ago

Would love if my security token could unlock my house/car. Would go a long way for me to convince others that keeping one of these keys is meaningful. As it is, the ones that go on a keychain are basically useless for the vast majority of people. Even folks that will be using a key often, are best off getting the micro that you leave in the device.

deleted 4y ago
[deleted]

juliangmp 4y ago

While I'm glad to see this be dome with the W3C (that way it can actually be standardized and used by more than just two platforms), I find it kind of odd that something like the Secure Remote Password protocol (SRP) hasn't seen much use. Or at least I haven't seen it, correct me if I'm wrong. That way the password is never known to the server and we also don't have to rely on hardware keys. Personally I don't know anyone using hardware keys, they're just annoying to use...

throwing_away 4y ago

> The user again proves possession of the authenticator and the device generates a response by signing the challenge with its private key. This sounds very similar to how hardware wallets work. I know some wallets support FIDO2, but I wonder if FIDO2 devices like yubikeys could also be used as hardware wallets. There are probably UX reasons why this isn't a good idea, but I wonder if the math would work.