Yubikey authentication trial on beta server

We’re currently running a trial of Yubikey authentication on our beta server.

To enable this, just login and go to Options -> Alternate Logins, and create a new Yubikey login set. For the Base Password, just touch your Yubikey button to generate a new one-time code to allow us to associate your particular Yubikey with your account. Currently these logins only work on the beta server web interface.

The Yubikey is a small USB authentication device that you can use to login to your FastMail account (beta web interface only at the moment) instead of your regular password. The Yubikey doesn’t need any client software. You just plug it into a USB port and it acts like a USB keyboard that most OS’s automatically support. It has one button on it, that when you press it, it generates a new one-time 44 character password.

The main advantage of a Yubikey login over a regular static password login is that to login, you must have the physical Yubikey token plugged into your machine, and you must press the button on it to generate a new one-time password. You can’t re-enter an already used one-time password, or copy and paste an existing one-time password. This prevents replay attacks if someone captures any of your logins (eg keylogger, tcp dump, malware root kit, etc).

Here’s the way it works:

1. Each device has a unique id, that’s the first 12 chars
2. Each device has an internal “shared secret” AES encryption key
3. Each time you press the button, it generates a new one-time value
   that encrypted with that key, that’s the other 32 characters

The way it generates the one-time value is like this:

1. It takes some internal values and joins them together
2. It then encrypts that data using a symmetric cipher with the shared
   AES key that’s stored in the Yubikey, and also on the Yubico server
   so the server can decrypt it

The internal values that are joined and encrypted include:

1. A private internal value
2. A number of counter fields (each time you plug the key into a
   machine, or generate a new key, internal non-volatile counters are
   incremented)
3. Timer field (an internal 8hz counter value)
4. A random number
5. A CRC checksum

So at the receiving side, you get the 44 char value. The first 12 chars normally let you work out who’s key it is (we still need to ask for your login name, because we you allow you to associate your Yubikey with multiple different accounts if you want). With the other 32 bytes, they are decrypted using the shared AES key, and then all the values are checked to make sure they are valid (eg counters are all higher than their previous values, checksum is valid, etc). There’s more details at the Yubico website (PDF manual).

So with this approach, you can validate a login, and be sure that if someone captures your keystrokes/one-time password value, it’s useless, because it can’t be used again.

We don’t actually store the AES key or do the decryption. That’s done with the Yubico web API service. So the shared key is stored in the Yubikey itself, and on the Yubico web service API server.

You can order Yubikeys from the Yubico website order page.

If you want to ask more questions, there’s a forum thread about this you can check out: Yubikey forum thread.

Update 22 Jan 2010: We’ve now added a two factor Yubikey authentication option. With this method, you need to enter both a password, and touch your Yubikey button to generate a one-time password. The advantage of this approach is that if you login on a machine with a keylogger/malware/root kit that captures your username + password + yubikey one time password, it doesn’t matter, because the yubikey one time password can’t be reused. If someone steals your physical Yubikey, then it doesn’t matter, because they don’t know your fixed static password. This is why it’s called “two factor” authentication. (Of course it doesn’t protect against the case of both the static password and physical key being stolen, but that’s a lot less likely)

Off topic: Just as an FYI, this isn’t related to the FastMail implementation, but it is neat. If you’re a business that wants to use Yubikeys for authenticating people within your own organisation, you can run your own Yubikey validation server rather than using the Yubico Web API one. In that case what you’d do is before handing the Yubikeys to people in your organisation, you’d reprogram them with you’re own new random AES code. You’d also store that AES code on your own validation server. This means staff could then use their Yubikey to validate against your organisations validation server. Of course it wouldn’t work for other externally run services that validate against the Yubico web API anymore, because the shared AES key is no longer valid in that case.