14 ms·

Using Yubikeys Everywhere

165 points by tdurden 10y ago

jlgaddis 10y ago
I just recently started using my Yubikeys (in Challenge-Response mode) w/ LUKS to unlock my drives at boot -- it's pretty neat! On my primary system (a workstation, at home), I use the Yubikey to house my GPG keys and I use the "derived" SSH key that lives inside of it for authenticating to everything at $work. It was a bit of a PITA to get working -- points at gnome keyring -- but it works great. I have a Nano I'm about to set up the same way and just leave it in my primary laptop permanently.
- SEJeff 10y ago
  What was the gist of it? I use LUKS with a pretty strong password on Fedora 25 and have a few Yubikeys I need to put to good use.
  - jlgaddis 10y ago
    gnome-keyring replaces gpg-agent and ssh-agent (on the system) but doesn't actually include all the functionality... basically, disable GPG/SSH agent support in gnome-keyring (if it's running -- and it's quite often automatically launched, even if you aren't aware of/expecting it), and explicitly use the real agent instead. You can find the details on Google, but it's one of things that you wouldn't even know was a problem to be aware of. Edit: Sorry... for LUKS, write a custom initramfs hook (shell script, in my case) to prompt the user for a "passphrase", use that as the challenge sent to the Yubikey, read the response from the Yubikey, write that to /crypto_keyfile.bin (in the initramfs, so not on disk), and the "encrypt" hook should use that file as the key to unlock the disk. You'll have to do it by hand once so that you can add the key (response) to a slot in LUKS. There's examples on Github of this but of course I didn't find them until I had already figured it out myself.
  - jeffmcjunkin 10y ago
    Amusingly I just ran across this[0] link an hour or so before this HN post went live. I haven't done it yet, but it looks pretty reasonable. I prefer not to mix LUKS with random many-year-old GitHub repos. [0] http://askubuntu.com/a/599826 http://askubuntu.com/a/599826
  - mmozeiko 10y ago
    Take a look at this: https://github.com/agherzan/yubikey-full-disk-encryption https://github.com/agherzan/yubikey-full-disk-encryption
- elithrar 10y ago
  > I have a Nano I'm about to set up the same way and just leave it in my primary laptop permanently. Do I misunderstand the purpose of a Yubikey/U2F device here? Is not leaving it plugged in permanently effectively reducing the strength of the second factor? With TOTP codes behind my iPhone lock screen I can be reasonably confident that stealing my laptop isn't enough to break into my accounts (buying time until I can contact our SIRT team), but with a device plugged in permanently I lose that. Obviously an attacker would have to know my password, but that assumption is a primary reason for multi-factor auth to begin with. What am I missing?
  - idlewords 10y ago
    The big win from a U2F device permanently plugged in to the laptop is as a defense against phishing.
  - petee 10y ago
    I believe its like using it as an HSM; keys are protected against a remote intruder copying them, but physical access is another issue - you should still use it in conjunction with something-you-know, then it doesn't matter if the laptop is stolen.
  - jlgaddis 10y ago
    Leaving it in permanently is mostly for convenience. The keys are still protected (by a "PIN") even if the laptop and/or Yubikey is stolen. There's also FDE on the laptop itself, protecting the data.
    - hdhzy 10y ago
      You can also turn on touch-to-use policy so that you have to touch the yubikey each time you want to use the key.
      - hvidgaard 10y ago
        This is important. Physical action outside the computer should be required to access keys, otherwise a root access is enough to completely compromise the system.
- rkeene2 10y ago
  I use a smartcard with an RSA key with a LUKS-like format to encrypt my disks -- uses AES256-XTS for the actual dm-crypt, the smartcard's key is used to encrypt the symmetric cipher key.
emgram769 10y ago
>This doesn’t have any effect on the phone, however. I have to tap back, return to the login screen, and enter my password again I believe you can simply hit the login button (sans code) after validating the login attempt instead of closing the application.
tptacek 10y ago
You can have a security key on Google without a phone number, but you have to enroll with a phone number and then remove it. Google won't allow you to remove the phone number unless you have some other backup 2FA method available. The best Google (actually: everywhere) 2FA "stack" in Q1 2017 is: 1. Hardware U2F 2. Software TOTP (Authenticator app on your phone) 3. Physically secured backup codes 4. Disabled SMS My experience with the Y4 hardware and, particularly, software has not been great. I'm using the Y4 for SSH access (through ssh-compat mode on gpg-agent) and it's mostly OK, but if I try to use PIV mode on the same token I run into all sorts of problems. I'm bullish on U2F, but bearish on Unix token applications.
- my_first_acct 10y ago
  I have a concern about software TOTP. As tptacek knows (but I'll mention as background for other readers), the various authenticator apps use the standardized TOTP algorithm [1]. This algorithm uses a private key that the server and the client (your phone) have in common. The question is, where is the private key stored on your phone? According to some posts from 2012 or so [2], on Android, Google Authenticator stores the key unencrypted in an sqlite database, which you can look at if you have rooted your phone. This seems insecure. Is this still an issue with Android? Are Apple products any better? [1] https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm https://en.wikipedia.org/wiki/Time-based_One-time_Password_A... [2] https://www.howtogeek.com/130755/how-to-move-your-google-authenticator-credentials-to-a-new-android-phone-or-tablet/ https://www.howtogeek.com/130755/how-to-move-your-google-aut...
  - tptacek 10y ago
    You should basically assume your TOTP secret on your phone is as secure, and no more secure, than any other piece of sensitive information on your phone. If you don't trust your phone, that's a good reason not to use your phone to generate TOTP secrets. For users like that, you can configure a Yubikey to function as a TOTP token (but it's a pain). For me, I trust my phone more than any other piece of computing equipment I own. I also rarely unlock my password manager on it, so there's no one attack that gets you everything you need by hitting either my phone or my computer. If I had a generic, non-Google Android phone, or any kind of rooted phone, the equation would be different for me.
drewg123 10y ago
For Google 2FA, I'm pretty sure that it lets you remove the phone number once you've added a 2nd 2FA mechanism. Eg, once you've setup Google Authenticator and a Yubikey. At least that's how it worked when I set it up a while ago. Given that Ted uses OpenBSD, I'm surprised that he has not mentioned the dumpster fire that is U2F on Chromium for BSD. This bug details the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=451248 https://bugs.chromium.org/p/chromium/issues/detail?id=451248. The last I checked, (~2 months ago), it was still a problem on FreeBSD. In order to avoid the crashes, I needed to set a user-agent spoofer to Firefox, so that I would not get a u2f prompt (and would instead be prompted for a Google Authenticator code). That became frustrating enough that I decided to try switching from Chrome to Firefox so that I could use my Yubikey. I had to setup a u2f plugin for firefox to use u2f on FreeBSD. And to even get u2f requests, I had to install a user agent spoofer, and spoof a chrome user agent. Argh! So now I was spoofing Firefox on Chromium, and spoofing Chrome on Firefox. My head was spinning, and (because the spoofer spoofed old agent strings), I was getting nastygrams from corp. sec. for running out of date, insecure browsers. I finally just threw in the towel, and set up a Linux bhyve VM to run Chrome under linux. The performance sucks, but at least I can finally use my Yubikeys. On the plus side, I can use PCI-passthru to pass in a webcam, and actually do hangouts on my desktop now.
- bb88 10y ago
  You can't have a U2F Key and a Mobile Phone Authentication at the same time with Google.
  - tptacek 10y ago
    What makes you think that?
    - bb88 10y ago
      Because I have a u2f key, and you have to disable the phone authentication in google.
      - 10y ago
ehPReth 10y ago
I ran into the same problem with ed25519 :/. Hopefully they upgrade and offer this at some point!
- dokument 10y ago
  neat. what are some use-cases for ed25519?
  - e12e 10y ago
    Ssh? https://lwn.net/Articles/590870/ https://lwn.net/Articles/590870/
deleted 10y ago
[deleted]
TimWolla 10y ago
Instead of using Yubikey through GPG to replace the SSH key one can also use the PKCS#11 module they provide: https://developers.yubico.com/PIV/Guides/SSH_user_certificates.html https://developers.yubico.com/PIV/Guides/SSH_user_certificat... This requires replacing GNOME keyring with SSH agents, though. One can also use one of the 20 additional slots (82-95) the Yubikey 4 provides over the Yubikey NEO by replacing the '9c' with '82'.
- arianvanp 10y ago
  Using it through GPG already required you to replace Gnome Keyring with gpg-agent. At least it did in the past.
elchief 10y ago
Tried my U2F yubikey on Chromium 48 on OpenBSD 5.9, but it crashed :(
Animats 10y ago
Too much trust centralization. How do you know Yubikey key generation hasn't been compromised? They're an obvious target.
- Godel_unicode 10y ago
  The logical end-state of this train of thinking is tamper-resistant key generation and storage, with fully published sources and audited assembly line production. Except then they need to ensure that all the equipment on their line was produced by trusted suppliers with the same level of disclosure. Ditto all software which touches anything in the manufacturing process. It's turtles all the way down, see also "on trusting trust".
  - nickpsecurity 10y ago
    Or just do it with open code & hardware on an ASIC whose process node is verifiable by eye with a microscope against a reference image after samples of it are decapped. Either by the owner or numerous third parties. You make it sound much harder than it is unless they're using unverifiable technology. In that case, it might be pretty hard. ;)
    - Godel_unicode 10y ago
      That's ridiculous. People can't reliably produce good implementations of crypto software, and you suggest they design and verify ASICs? My point was that security is about understanding and accepting, not foolishly trying to eliminate, risk. Just a few of the mountains which need climbing: First, you'd need a (actually) random sampling not just one (keep in mind any ASIC you test is likely a write-off due to tamper-resistance). You'd also need a high assurance supply chain to ensure your verification isn't premature (as well as sufficient levels of tamper resistance/evidence). You'd further need to verify the software around this hypothetical ASIC is free of bugs. You're restricting yourself to software which can be performant on older slower process nodes. You (almost certainly not an ASIC company) need to have an in-house ASIC shop, or you need to vet an external one (sounds cheap and easy for the average business). In fact, you need vetting of your internal staff at all stages of this process. You are making this seem _much_ easier than it is. There's a reason this product, which there is definitely a market for, doesn't exist (and that reason is much more mundane than the cryptolluminati not wanting it to "get out"). Consider that Google did something like what you're suggesting. It took them years (and they're Google), what chance does the average person/SMB have?
Jaruzel 10y ago
This article shows that U2F has LONG way to go before it is consumer ready. Expanding on the 'key' metaphor, U2F (or MFA in general) needs to be as easy as unlocking a door. Everyone knows how to do that; insert key, turn key, open door. Until things like Yubikey and their ilk are as simple as this (and I know it's mostly the software that has to catch up), it's never going to be wildly adopted on peoples personal logins. I use Smart-card auth on my work laptop along with a 8 digit PIN to create 2FA, and although it's supposed to be universally supported across all the applications I use, it really isn't. When I first started working here, I spent several days very confused about where the smart-card did and didn't work - I dread to think how the layperson works this stuff out.
- homakov 10y ago
  I absolutely agree that it is not consumer ready. I'm trying to fix sharp corners with Truefactor.io, any thoughts?
nicolas314 10y ago
There is still one issue left with Yubikeys: backups. When I loose my Yubikey after I cautiously registered it with a hundred different sites and servers, I would like to restore its secrets onto a brand new (blank) Yubikey and go forward. The only official course of action given by Yubico today is to manually un-register and re-register on all sites and servers. Of course the key backup should be correctly protected, but that problem is not hard to solve.
talkingtab 10y ago
- U2F is a standard - The FIDO Alliance is the body that maintains the U2F standard. U2F keys can be "FIDO Certified" if they comply to the standard and have been tested. - Yubico is a company and Yubikey is a brand. Yubikeys often support more than U2F so some Yubikeys are much more expensive than a key supporting only U2F. - Prices start at ~$10 for a FIDO certified key - U2F Zero is an open source project, not FIDO certified. - I have three U2F keys of various brands and they all seem equivalent so far.
dllthomas 10y ago
eiecccevfhqwhgadshgnsdhjsdbkhsdabkfabkveybvf

165 points by tdurden 10y ago

I just recently started using my Yubikeys (in Challenge-Response mode) w/ LUKS to unlock my drives at boot -- it's pretty neat! On my primary system (a workstation, at home), I use the Yubikey to house my GPG keys and I use the "derived" SSH key that lives inside of it for authenticating to everything at $work. It was a bit of a PITA to get working -- points at gnome keyring -- but it works great. I have a Nano I'm about to set up the same way and just leave it in my primary laptop permanently.

SEJeff 10y ago
What was the gist of it? I use LUKS with a pretty strong password on Fedora 25 and have a few Yubikeys I need to put to good use.
- jlgaddis 10y ago
  gnome-keyring replaces gpg-agent and ssh-agent (on the system) but doesn't actually include all the functionality... basically, disable GPG/SSH agent support in gnome-keyring (if it's running -- and it's quite often automatically launched, even if you aren't aware of/expecting it), and explicitly use the real agent instead. You can find the details on Google, but it's one of things that you wouldn't even know was a problem to be aware of. Edit: Sorry... for LUKS, write a custom initramfs hook (shell script, in my case) to prompt the user for a "passphrase", use that as the challenge sent to the Yubikey, read the response from the Yubikey, write that to /crypto_keyfile.bin (in the initramfs, so not on disk), and the "encrypt" hook should use that file as the key to unlock the disk. You'll have to do it by hand once so that you can add the key (response) to a slot in LUKS. There's examples on Github of this but of course I didn't find them until I had already figured it out myself.
- jeffmcjunkin 10y ago
  Amusingly I just ran across this[0] link an hour or so before this HN post went live. I haven't done it yet, but it looks pretty reasonable. I prefer not to mix LUKS with random many-year-old GitHub repos. [0] http://askubuntu.com/a/599826 http://askubuntu.com/a/599826
- mmozeiko 10y ago
  Take a look at this: https://github.com/agherzan/yubikey-full-disk-encryption https://github.com/agherzan/yubikey-full-disk-encryption
elithrar 10y ago
> I have a Nano I'm about to set up the same way and just leave it in my primary laptop permanently. Do I misunderstand the purpose of a Yubikey/U2F device here? Is not leaving it plugged in permanently effectively reducing the strength of the second factor? With TOTP codes behind my iPhone lock screen I can be reasonably confident that stealing my laptop isn't enough to break into my accounts (buying time until I can contact our SIRT team), but with a device plugged in permanently I lose that. Obviously an attacker would have to know my password, but that assumption is a primary reason for multi-factor auth to begin with. What am I missing?
- idlewords 10y ago
  The big win from a U2F device permanently plugged in to the laptop is as a defense against phishing.
- petee 10y ago
  I believe its like using it as an HSM; keys are protected against a remote intruder copying them, but physical access is another issue - you should still use it in conjunction with something-you-know, then it doesn't matter if the laptop is stolen.
- jlgaddis 10y ago
  Leaving it in permanently is mostly for convenience. The keys are still protected (by a "PIN") even if the laptop and/or Yubikey is stolen. There's also FDE on the laptop itself, protecting the data.
  - hdhzy 10y ago
    You can also turn on touch-to-use policy so that you have to touch the yubikey each time you want to use the key.
    - hvidgaard 10y ago
      This is important. Physical action outside the computer should be required to access keys, otherwise a root access is enough to completely compromise the system.
rkeene2 10y ago
I use a smartcard with an RSA key with a LUKS-like format to encrypt my disks -- uses AES256-XTS for the actual dm-crypt, the smartcard's key is used to encrypt the symmetric cipher key.

emgram769 10y ago

>This doesn’t have any effect on the phone, however. I have to tap back, return to the login screen, and enter my password again I believe you can simply hit the login button (sans code) after validating the login attempt instead of closing the application.

tptacek 10y ago

You can have a security key on Google without a phone number, but you have to enroll with a phone number and then remove it. Google won't allow you to remove the phone number unless you have some other backup 2FA method available. The best Google (actually: everywhere) 2FA "stack" in Q1 2017 is: 1. Hardware U2F 2. Software TOTP (Authenticator app on your phone) 3. Physically secured backup codes 4. Disabled SMS My experience with the Y4 hardware and, particularly, software has not been great. I'm using the Y4 for SSH access (through ssh-compat mode on gpg-agent) and it's mostly OK, but if I try to use PIV mode on the same token I run into all sorts of problems. I'm bullish on U2F, but bearish on Unix token applications.

my_first_acct 10y ago
I have a concern about software TOTP. As tptacek knows (but I'll mention as background for other readers), the various authenticator apps use the standardized TOTP algorithm [1]. This algorithm uses a private key that the server and the client (your phone) have in common. The question is, where is the private key stored on your phone? According to some posts from 2012 or so [2], on Android, Google Authenticator stores the key unencrypted in an sqlite database, which you can look at if you have rooted your phone. This seems insecure. Is this still an issue with Android? Are Apple products any better? [1] https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm https://en.wikipedia.org/wiki/Time-based_One-time_Password_A... [2] https://www.howtogeek.com/130755/how-to-move-your-google-authenticator-credentials-to-a-new-android-phone-or-tablet/ https://www.howtogeek.com/130755/how-to-move-your-google-aut...
- tptacek 10y ago
  You should basically assume your TOTP secret on your phone is as secure, and no more secure, than any other piece of sensitive information on your phone. If you don't trust your phone, that's a good reason not to use your phone to generate TOTP secrets. For users like that, you can configure a Yubikey to function as a TOTP token (but it's a pain). For me, I trust my phone more than any other piece of computing equipment I own. I also rarely unlock my password manager on it, so there's no one attack that gets you everything you need by hitting either my phone or my computer. If I had a generic, non-Google Android phone, or any kind of rooted phone, the equation would be different for me.

drewg123 10y ago

For Google 2FA, I'm pretty sure that it lets you remove the phone number once you've added a 2nd 2FA mechanism. Eg, once you've setup Google Authenticator and a Yubikey. At least that's how it worked when I set it up a while ago. Given that Ted uses OpenBSD, I'm surprised that he has not mentioned the dumpster fire that is U2F on Chromium for BSD. This bug details the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=451248 https://bugs.chromium.org/p/chromium/issues/detail?id=451248. The last I checked, (~2 months ago), it was still a problem on FreeBSD. In order to avoid the crashes, I needed to set a user-agent spoofer to Firefox, so that I would not get a u2f prompt (and would instead be prompted for a Google Authenticator code). That became frustrating enough that I decided to try switching from Chrome to Firefox so that I could use my Yubikey. I had to setup a u2f plugin for firefox to use u2f on FreeBSD. And to even get u2f requests, I had to install a user agent spoofer, and spoof a chrome user agent. Argh! So now I was spoofing Firefox on Chromium, and spoofing Chrome on Firefox. My head was spinning, and (because the spoofer spoofed old agent strings), I was getting nastygrams from corp. sec. for running out of date, insecure browsers. I finally just threw in the towel, and set up a Linux bhyve VM to run Chrome under linux. The performance sucks, but at least I can finally use my Yubikeys. On the plus side, I can use PCI-passthru to pass in a webcam, and actually do hangouts on my desktop now.

bb88 10y ago
You can't have a U2F Key and a Mobile Phone Authentication at the same time with Google.
- tptacek 10y ago
  What makes you think that?
  - bb88 10y ago
    Because I have a u2f key, and you have to disable the phone authentication in google.
    - 10y ago

ehPReth 10y ago

I ran into the same problem with ed25519 :/. Hopefully they upgrade and offer this at some point!

dokument 10y ago
neat. what are some use-cases for ed25519?
- e12e 10y ago
  Ssh? https://lwn.net/Articles/590870/ https://lwn.net/Articles/590870/

deleted 10y ago

[deleted]

TimWolla 10y ago

Instead of using Yubikey through GPG to replace the SSH key one can also use the PKCS#11 module they provide: https://developers.yubico.com/PIV/Guides/SSH_user_certificates.html https://developers.yubico.com/PIV/Guides/SSH_user_certificat... This requires replacing GNOME keyring with SSH agents, though. One can also use one of the 20 additional slots (82-95) the Yubikey 4 provides over the Yubikey NEO by replacing the '9c' with '82'.

arianvanp 10y ago
Using it through GPG already required you to replace Gnome Keyring with gpg-agent. At least it did in the past.

elchief 10y ago

Tried my U2F yubikey on Chromium 48 on OpenBSD 5.9, but it crashed :(

Animats 10y ago

Too much trust centralization. How do you know Yubikey key generation hasn't been compromised? They're an obvious target.

Godel_unicode 10y ago
The logical end-state of this train of thinking is tamper-resistant key generation and storage, with fully published sources and audited assembly line production. Except then they need to ensure that all the equipment on their line was produced by trusted suppliers with the same level of disclosure. Ditto all software which touches anything in the manufacturing process. It's turtles all the way down, see also "on trusting trust".
- nickpsecurity 10y ago
  Or just do it with open code & hardware on an ASIC whose process node is verifiable by eye with a microscope against a reference image after samples of it are decapped. Either by the owner or numerous third parties. You make it sound much harder than it is unless they're using unverifiable technology. In that case, it might be pretty hard. ;)
  - Godel_unicode 10y ago
    That's ridiculous. People can't reliably produce good implementations of crypto software, and you suggest they design and verify ASICs? My point was that security is about understanding and accepting, not foolishly trying to eliminate, risk. Just a few of the mountains which need climbing: First, you'd need a (actually) random sampling not just one (keep in mind any ASIC you test is likely a write-off due to tamper-resistance). You'd also need a high assurance supply chain to ensure your verification isn't premature (as well as sufficient levels of tamper resistance/evidence). You'd further need to verify the software around this hypothetical ASIC is free of bugs. You're restricting yourself to software which can be performant on older slower process nodes. You (almost certainly not an ASIC company) need to have an in-house ASIC shop, or you need to vet an external one (sounds cheap and easy for the average business). In fact, you need vetting of your internal staff at all stages of this process. You are making this seem _much_ easier than it is. There's a reason this product, which there is definitely a market for, doesn't exist (and that reason is much more mundane than the cryptolluminati not wanting it to "get out"). Consider that Google did something like what you're suggesting. It took them years (and they're Google), what chance does the average person/SMB have?

Jaruzel 10y ago

This article shows that U2F has LONG way to go before it is consumer ready. Expanding on the 'key' metaphor, U2F (or MFA in general) needs to be as easy as unlocking a door. Everyone knows how to do that; insert key, turn key, open door. Until things like Yubikey and their ilk are as simple as this (and I know it's mostly the software that has to catch up), it's never going to be wildly adopted on peoples personal logins. I use Smart-card auth on my work laptop along with a 8 digit PIN to create 2FA, and although it's supposed to be universally supported across all the applications I use, it really isn't. When I first started working here, I spent several days very confused about where the smart-card did and didn't work - I dread to think how the layperson works this stuff out.

homakov 10y ago
I absolutely agree that it is not consumer ready. I'm trying to fix sharp corners with Truefactor.io, any thoughts?

nicolas314 10y ago

There is still one issue left with Yubikeys: backups. When I loose my Yubikey after I cautiously registered it with a hundred different sites and servers, I would like to restore its secrets onto a brand new (blank) Yubikey and go forward. The only official course of action given by Yubico today is to manually un-register and re-register on all sites and servers. Of course the key backup should be correctly protected, but that problem is not hard to solve.

talkingtab 10y ago

- U2F is a standard - The FIDO Alliance is the body that maintains the U2F standard. U2F keys can be "FIDO Certified" if they comply to the standard and have been tested. - Yubico is a company and Yubikey is a brand. Yubikeys often support more than U2F so some Yubikeys are much more expensive than a key supporting only U2F. - Prices start at ~$10 for a FIDO certified key - U2F Zero is an open source project, not FIDO certified. - I have three U2F keys of various brands and they all seem equivalent so far.

dllthomas 10y ago

eiecccevfhqwhgadshgnsdhjsdbkhsdabkfabkveybvf