Image of the glider from the Game of Life by John Conway
Skip to content

The Yubikey

I'm absolutely pedantic about password security with every one of my accounts. A couple of years ago, I watched as friends and family members seemed to have their Google, Twitter, Facebook or other accounts compromised. In every case, it was because they were using a weak password, and they knew it. I resolved to make sure every online account I had, used a different random password and that the passwords contained at least 80 bits of entropy. When Google released their two-factor authentication, I immediately enabled it. After discovering the Password Card, I've been using it religiously to select the passwords for all of my accounts. Just in case I forget a password, I've kept them stored in KeePassX. This system has been working very well for me, and I couldn't imagine improving it anytime soon. That is, until I learned about the Yubikey.

Actually, I heard about the Yubikey a few years ago, it seems. I remember stumbling upon it on some web site, and not thinking much about it. That is, until I was browsing Silk Road on Tor, and saw that they were selling Yubikeys for Bitcoin. My interest peaked, so I found the Yubico website, and read up about Yubikeys. Within the hour, I ordered one. Two days later (!!!) it was delivered, and in my hands to play with. Since playing with it, I figured I'd write up a quick review.

The Yubikey is a hardware password generator that presents itself as a keyboard to the computer. As such, there is no special software or hardware drivers to interact with the Yubikey. Even when the computer is not booted into an operating system, it can still accept input from the key. This could be useful for entering administrator passwords at the BIOS or providing the encryption passphrase when booting.

There are four types of password generation that firmware version 2.2 (which is Free Software) of the key supports:

  1. Yubikey OTP- Default behavior shipped with the key. A symmetric AES key is used to create one-time encrypted passwords using the TOTP protocol (similar to the RSA SecureID). This encrypted key is sent to the Yubico servers to authenticate the session.
  2. Open Authentication (OATH)- The Yubikey can be configured to generate 6- or 8-digit one-type passwords that work with the VeriSign OATH standard.
  3. Static Password- Rather than dynamic passwords at every authentication session, static passwords can be configured. Anything between 16- to 64-character passwords can be set.
  4. Challenge-Response- Client applications can take advantage of the Yubikey API, which supports both Yubikey OTP and HMAC-SHA1.

The key came shipped with two configuration slots. In the first slot, it was pre-programmed to support Yubikey OTP with their servers. When ordering my key, I had every intention of running my own Yubikey server (which is Free Software), and authenticating that way instead of trusting Yubico. However, I ran into a snag. When generating a new AES key, and uploading it to the server, authentication was always failing with "OTP prefix mismatch". I couldn't tell if there was something wrong with my server, or my client, or my key, or what. I tried over, and over, and over to get it right. Finally, in a bit of desperation, I sent an email to support to ask for help. Turns out, because I'm a Dvorak typist, and because the Yubikey is sending keycode presses, not actual characters, the OTP key was "in Dvorak" rather than "in QWERTY" as the server is expecting. I did stumble across http://wiki.yubico.com/wiki/index.php/YubiKeyIdeas#Dvorak_support as a way to integrate Dvorak into the authentication, but the more I thought about it, the more I didn't like it.

So, I eventually decided to program both slots with static passwords. This allows me to remain completely "offline" without the need to authenticate against a server. Further, because I'll likely be typing my usernames and passwords in Dvorak in the authentication form already, having the key give a "Dvorak" password is no big deal. In fact, you could think of this as a bit of obscurity. If an attacker knows my password, and gets the key, using the key in QWERTY will result in a different password than in Dvorak.

At any event, in the first slot, I configured it for the shortest static password of 16 characters. This is to appease silly developers who think it's funny to limit the length of passwords in their form fields. In the second slot, I configure it for the longest static password of 64 characters. And, rather than use the client (which is Free Software) PRNG to generate the password for me, I pulled the data out of /dev/random on my local machine, to ensure high quality randomness. I then stored all the details in my KeePassX database.

So, how does this work? Well, I generate the first part of the password using the password card. Suppose it's "8%FtaKbb*3EmCZwT". I then use the Yubikey to fill in the rest. If the password form has limits on password length, I'll press the Yubikey button for one second, and will get a string like: "15KBjnducnkhnebc". So, the password for the account would then be "8%FtaKbb*3EmCZwT15KBjnducnkhnebc" for a total password length of 33 characters, with an entropy of 210 bits. The great thing about this setup, is it creates a pseudo-two-factor authentication. The password "8%FtaKbb*3EmCZwT" is something you know, and the Yubikey is something you have. So for every account, you can have this simple two-factor authentication without much headache. And, unless you spend time memorizing the Yubikey password, you can say with 100% honesty that you do not know the password to the account to law enforcement or bad guys.

Aside from web accounts, this setup is fairly flexible: SSH keys, OpenPGP keys, SSL certificates, local machine accounts, encrypted filesystem passphrases, BIOS admin accounts, etc. Even better, Yubico produces and ships RFID and NFC Yubikeys for wireless authentication as well. And because all of the firmware and software is Free and Open Source Software, you have full platform support for Windows, Mac OS X and GNU/Linux. You can have your cake, and eat it too.

Now the only thing left to do, is update all my passwords to use both the password card and the Yubikey. :)

{ 6 } Comments

  1. Joseph Scott using Google Chrome 23.0.1271.52 on Mac OS | October 30, 2012 at 12:53 pm | Permalink

    This is to appease silly developers who think it’s funny to limit the length of passwords in their form fields.

    I confess to having the same feelings about password length limits. Then I ran into bcrypt/blowfish only paying attention to the first 72 characters of a string. So now I'm looking at limiting password strings to 72 characters. Still a decent amount, but doesn't quite feel the same as allowing passwords of any length.

  2. Alexandre Franke using Firefox 16.0 on GNU/Linux | October 30, 2012 at 2:41 pm | Permalink

    You may want to look at Clipperz and consider it as a replacement to KeePassX.

  3. Aaron Toponce using Google Chrome 24.0.1305.3 on Mac OS | October 31, 2012 at 6:51 am | Permalink

    Joseph- Even though bcrypt/blowfish imposes the limit internally, why bother with it externally?

    Alexandre- No thanks. I don't buy into the security of online password managers. I would much rather prefer to manage my passwords without the help of an online 3rd party.

  4. Alexandre Franke using Firefox 16.0 on GNU/Linux | November 13, 2012 at 1:59 am | Permalink

    It seems you didn't pay enough attention when looking it up.

    Clipperz:
    * can be installed on your own server (or your desktop provided you have a local web server) as it's free software
    * doesn't store your passwords as it uses a zero knowledge paradigm

  5. Joseph Scott using Google Chrome 24.0.1312.5 on Mac OS | November 13, 2012 at 8:15 am | Permalink

    The reason for passing along bcrypt's 72 character limit is password collisions. Here is an example: say Alice has a password that is 100 characters long and Bob has a password that is 80 characters long. If they both start with the same 72 characters then for your system those passwords are identical. I consider that a condition to be avoided.

    I came up with a few methods for working around this limitation and discussed it with the author of phpass. Ultimately there were some work arounds that likely didn't reduce the security of the hashes, but the safest stance was still to limit user password strings to 72 characters to ensure uniqueness.

  6. Aaron Toponce using Debian IceWeasel 10.0.10 on GNU/Linux 64 bits | November 25, 2012 at 10:19 pm | Permalink

    Alexandre Franke- Still, it's on online password managar. It requires running software on an external server, whether you own the server or not. This isn't something I'm interested in.

Post a Comment

Your email is never published nor shared.

Switch to our mobile site