using yubikeys everywhere
It’s not a secret I’ve had a dim view of two factor auth, although many of my gripes are about implementation details. I think a lot of that remains true. Where two factor auth perhaps might succeed is in limiting the damage of phishing attacks. I like to think of myself as a little too savvy for most phishing attacks. That’s sadly true of most phishing victims as well, but really: I don’t use webmail. I don’t have any colleagues sharing documents with me. I read my mail in a terminal, thus on the rare occasion that I copy and paste a link, I see exactly the URL I’m going to, not the false text between the <a> tags. Nevertheless, if everybody else recommends secure tokens, I should at least consider getting on board with that recommendation. But not before actually trying these things out.
To begin with, I ordered two yubikeys. One regular sized 4 and one nano. I wanted to play with different form factors to see which is better for various uses, and I wanted to test having a key and a backup key. Everybody always talks about having one yubikey. And then if you lose it, terrible things happen. Can this problem be alleviated with two keys? I’m also very curious what happens when I try to login to a service with my phone after enabling U2F.
We’ve got three computers (and operating systems) in the mix, along with a number of (mostly web) services. Wherever possible, I want to use a yubikey both to login to the computer and to authorize myself to remote services. I’m somewhat split on the decision to use a yubikey for two factor vs alternative factor. I’ll consider either.
I started my adventure on my chromebook. Ultimate goal would be to use the yubikey for local logins. Either as a second factor, or as an alternative factor. First things first and we need to get the yubikey into the account I use to sign into the chromebook. Alas, there is apparently no way to enroll only a security key for a Google account. Every time I tried, it would ask me for my phone number. That is not what I want. Zero stars.
I guess some other people somehow got this working, but not me. I start at Add a Security Key and click the link. I enter my password. I click Get Started. I enter my password for the second time in ten seconds. I am now asked “What phone number do you want to use?” I can see no way to proceed without answering this question. (So the story is you can add a number and then delete it later. I don’t like that. Even choosing to trust Google with my number, there’s no assurance (at this stage) that the number can be deleted. Since I absolutely do not want SMS password resets, there’s no way I’m entering my phone number here.)
Giving up on protecting the chromebook itself, at least maybe I can use it to enable U2F with some other sites. U2F is currently limited to Chrome, but it sounds like everything I want. (Chrome, not chromium. BSD chromium support for U2F is worse than nothing.)
Facebook signup using U2F was pretty easy. Go to account settings, security subheading, add the device. Tap the button when it glows. Key added. Note that it’s possible to add a key without actually enabling two factor auth, in which case you can still login with only a password, but no way to login with no password and only a USB key. Logged out to confirm it would check the key, and everything looked good, so I killed all my other active sessions. Now for the phone test. Not quite as smooth. Tried to login, the Facebook app then tells me it has sent me an SMS and to enter the code in the box. But I don’t have a phone number attached. I’m not getting an SMS code.
Meanwhile, on my laptop, I have a new notification about a login attempt. Follow the prompts to confirm it’s me and permit the login. 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. This time the login succeeds. So everything works, but there are still some rough patches in the flow. Ideally, the phone would more accurately tell me to visit the desktop site, and then automatically proceed after I approve. (The messenger app crashed after telling me my session had expired, but upon restarting it was able to borrow the Facebook app credentials and I was immediately logged back in.)
Later, I logged out and logged in again on my phone with just a password because during the approval process I had selected the option to remember this device. This is somewhat confusing because the message appears in Chrome and refers to “this browser” but it’s actually talking about the app on my phone. Doing it over, I would choose the option not to remember. I trust my phone, but if I logout of Facebook, it’s for good reason. More clarity here would be nice as well.
Let’s configure Dropbox next. Dropbox won’t let you add a security key to an account until after you’ve already set up some other mobile authenticator. I already had the Duo app on my phone, so I picked that, and after a short QR scan, I’m ready to add the yubikey. So the key works to access Dropbox via Chrome. Accessing Dropbox via my phone or Firefox requires entering a six digit code. No way to use a yubikey in a three legged configuration.
I don’t use Github, but I know they support two factors, so let’s try them next. Very similar to Dropbox. In order to set up a key, I must first set up an authenticator app. This time I went with Yubico’s own desktop authenticator. Instead of scanning the QR code, type in some giant number (on my Windows laptop), and it spits out an endless series of six digit numbers, but only while the yubikey is inserted. I guess this is kind of what I want, although a three pound yubikey is kind of unwieldy. (I’m not clear exactly how this works, but after more investigation, some number of TOTP secret keys can be stored on the yubikey. But I think only the yubikey 4 series, which confused me. Otherwise the keys are encrypted using the credentials in one of the slots? It is possible to install the program on another computer and access them from the same key, at least with my yubikey.) Of course, having made it this far, adding the key in U2F mode is smooth and easy.
For our online services review, ok marks for Dropbox and Github (and I imagine many other sites). I would prefer some means to enroll only a yubikey, instead of using it as an alternative. Some incomplete UI interactions aside, Facebook seems to have implemented exactly what I want. I can login with the key, without needing anything else. For devices like my phone, this requires (configurably one time or every time) approval from my laptop. Possibly cumbersome, but it was actually easier than typing TOTP tokens in. And less stressful, since there’s no need to race the clock. I’ve always felt like only six digits for TOTP codes is too short, even if they do expire quickly, so I’m happy to avoid them if I can. Hopefully these are true second factors and not actually single factors that can be used to perform a password reset.
As part of my experiment, I noticed that Dropbox verifies passwords before even looking at the second auth. I have a feeling that they should be checked at the same time. No sense allowing my password guessing attack to proceed while I plot how to steal someone’s yubikey. In a sense, the yubikey should serve as a salt, preventing me from mounting such an attack until I have it, thus creating a race where the victim notices the key is gone and revokes access before I learn the password. If I know the password, the instant I grab the key I get access. Along similar lines, I was able to complete a password reset without entering any kind of secondary code.
In the course of writing this up, I went back and had another look at my Facebook settings. I also have a code generator enabled there, which is yet another TOTP implementation. I must have enabled this at some point in the past and forgotten it. Doing everything again, Facebook also won’t let me enable two factor without configuring a mobile app to use the code generator. So the above is partly wrong; it’s only what I’d hoped to see. Still, bonus points awarded for letting me use an authenticated desktop session to approve other logins. Ideally, these three legged setups would reverify that the U2F key is present. Facebook did allow me to approve my phone login without pressing the button. I’m a little confused though how the FB mobile app generates login tokens for itself. I guess there could be a bug here that if you only have the mobile app generator and you logout you can’t login? Wonder how many people get burned by that.
Having my phone turn into a second factor is a big part of what I’m looking to avoid with the yubikey. I’d like to be able to take my phone with me, logged into some sites but not all, and unable to login to the rest. All these sites that require using my phone as mobile authenticator are making that difficult. I bought the yubikey because it was cheaper than buying another phone! Using the Yubico desktop authenticator seems the best way around that.
In the course of fooling around I read that there are some sites that allow using OTP against Yubico’s servers? I didn’t try that.
Next I tried setting up a Windows laptop to require a yubikey to login. The Yubico Windows logon utility wants to use HMAC challenge response mode. So first we run the personalization and configuration utility to set that up, then run the login utility and configure the tedu account to use a key. This is mostly just a matter of clicking ok a bunch of times, and then everything is set. Reboot, and it mostly works. If the key is missing, the error message you get is literally “Status:” followed by an OK button. Otherwise though the challenge response happens magically in the background. You just enter your password as normal and proceed.
I have also a Windows desktop, and in the course of searching for and downloading the Yubi logon program, discovered that there is support for Windows Hello. This would let me login with just the yubikey, no password. OK, let’s try it that way for this machine. First, this requires setting a PIN for the Windows account. Do that and discover that anybody with the PIN can login. No password required! The yubikey hello app registers itself as a third way to login (password, PIN, yubi) but not as an accessory for the PIN. Immediately unregister key and delete PIN. I’d be ok with password or yubikey, but I’m very not ok with a PIN like 4321 also permitting login. This is terrible!
OpenBSD includes yubikey OTP login support out of the box. This is the classic mode where you touch the capacitive button and it sprays a password out via virtual keyboard. First, login.conf needs a tweak. This suffices to enable yubikey support for all users (in place of skey support).
Then we create a few files in /var/db/yubikey just like it says in the login_yubikey man page. Since the Windows challenge response key was written to slot 2, I setup new OTP keys in slot 1. This overrides the factory OTP config, which they warn against doing. But since the OTP keys are essentially a plaintext password, I’d prefer not to share them with anybody’s cloud service. Doesn’t everyone change the default password when they get a new device? I left password auth enabled as the default, but it’s easy to change the order. Depending on which program you’re using, the procedure for selecting a login style varies. For login, such as at the console, it’s username:style, meaning I might try tedu:yubikey. For xlock, which doesn’t ask for a username, it’s style:password, so I would either type my password or yubikey:bananaspray.
A few notes about OTP. As mentioned, the secret key is the real password. It’s stored on whatever laptop or server you login to. Meaning any of those machines can take the key and use it to login to any other machine. If you use the same yubikey to login to both your laptop and a remote server, your stolen laptop can trivially be used to login to the server without the key. Be mindful of that when setting up multiple machines. Also, the OTP counter isn’t synced between machines in this setup, which allows limited replay attacks.
One extremely simple alternative is to continue using ssh keys, but program the yubikey with a passphrase that unlocks the private key, thus tying access to the yubikey. This isn’t really a great idea, but I wanted to mention the static passphrase feature because it works with softraid crypto. At least on my X1, anyway; probably wise to verify that USB keyboards are supported in the bootloader before going all in.
This is the part where using ssh keys on the yubikey would be described, but no. I went to the trouble of rolling all my identity keys to ed25519 not that long ago, and I’m not doing it over. I notice that the new yubikeys claim to support at least some ECC p curves, but the funny thing is that there’s almost no official documentation. Instead, Yubico just points to some random blog and forum posts, most of which are somewhat older and specify that only RSA is supported. And then I notice that all these easy peasy instructions on getting started with gpg-agent run to many pages in length, so I think I’ll sit this round out.
Comparing the way OpenBSD and Windows do things, Windows is a little more transparent. The presence of the yubikey is invisible. And yet, I also like the OpenBSD way of allowing yubikey to be the sole auth mechanism. Some people use passwords, but I prefer epic passpoems detailing the rise and fall of REO Speedwagon. I’m fairly confident I’d like to keep that as a sole “backup” login mechanism, but am happy to find an option that works a little faster day to day.
I did most of my experimenting with the larger yubikey, since it was easier to move between machines. For operations involving logging into a web site, however, I’d prefer the nano. It’s very small, even smaller than the tiniest wireless mouse transcievers I’ve seen. So small, in fact, I had trouble removing it because I couldn’t find anything small enough to fit through the tiny loop. But probably a good thing. Most other micro USB gadgets stick out just enough to snag when pushing a laptop into a bag. Not the nano. You lose a port, but there’s really no reason to ever take it out. Just leave it in, and then tap it whenever you login to the tubes. It would not be a good choice for authenticating to the local machine, however. The larger device, sized to fit on a keychain, is much better for that.
It is possible to use two keys as backups. Facebook and Dropbox allow adding two U2F keys. This is perhaps a little tiresome if there’s lots of sites, as I see no way to clone a key. You have to login to every service. For challenge response and OTP, however, the personalization tool makes it easy to generate lots of yubikeys with the same secrets.
On the other hand, a single device supports an infinite number of U2F sites. The programmable interfaces like OTP are limited to only two slots, and the first is already used by the factory OTP setup.
It would be cool to use U2F to login to OpenBSD.