|
|
Subscribe / Log in / New account

Fedora accepting YubiKey one-time passwords

By Jake Edge
October 13, 2010

Some Fedora hosts and services have recently added a new authentication mechanism which uses a USB device that generates one-time passwords (OTPs). The YubiKey doesn't require any client-side software because it acts like a USB keyboard. In addition, the server-side authentication software, as well as a client-side utility to update the YubiKey, are open source. Like most security measures, hardware-based OTPs have advantages and disadvantages. But, when an OTP is combined with another authentication method—a regular password for example—it can provide a two-factor authentication that is much more secure.

YubiKeys came into Fedora to provide two-factor authentication for access to sensitive servers, like those that contain the keys for signing Fedora packages. Now that the infrastructure team has gotten that working, it decided to allow other Fedora users to use their own YubiKeys for single-factor authentication to things like ssh access to fedorapeople.org or signing in to the Fedora Community site.

The YubiKey uses symmetric encryption, which means that both the YubiKey and the server must share an AES secret key. The YubiKey comes from the factory with a pre-installed key that is shared with Yubico's server. For Fedora's purposes, users will run fedora-burn-yubikey when they first get the device. That script will generate a key on the server that also gets burned into the YubiKey.

To use the device, users plug it into the USB port on the machine they are using, put the cursor in the password prompt field, and press a button on the YubiKey. That will generate an OTP and a carriage return into the field. The OTP contains a serial number that gets incremented each time the YubiKey is used. Invalidating an exposed (but unused) OTP is done by properly authenticating with the server, thus incrementing the serial number past the exposed password.

The server ensures that each password can only be used once by tracking the serial number for each AES key it knows about. Even if an attacker were able to capture the AES key somehow—the YubiKey device has no means to read it out directly—he must also use a serial number that is greater than the last one used by the owner. If that happened, the next legitimate attempt to authenticate using the YubiKey would fail (because its serial number is now too low), which would be a clear indication of key compromise.

Obviously, physical security of the YubiKey is paramount. An attacker that gets access to it for even a short time can easily—largely undetectably—authenticate as the owner. Since OTPs that have been used are no longer valid, sniffing password entry on the wire or "keystroke" logging won't be of any assistance to an attacker—by the time the password is known, it's no longer useful.

After Mike McGrath announced YubiKey support on the fedora-devel mailing list, there was some discussion of the device and possible attacks against it. One of the concerns raised was with the potential sharing of AES keys between servers. If a user wanted to use the same device with multiple YubiKey-enabled sites, they would need to share their AES key with all of the servers. If any one of those servers was compromised, it would allow an attacker to authenticate to any of the others.

For a number of reasons, this attack scenario was considered to be unlikely. It would take explicit action by the user—or a compromised client machine—when writing the AES key to the YubiKey to record the key before it gets written. Presumably users who are purchasing YubiKeys will be security-conscious enough to recognize that it is a bad idea to record the AES key. McGrath also made the window of exposure quite small:

I had this [attack] in mind when I designed the burn script. The key never touches the drive during the burning process [so the] attack window here, while real, is very tiny. Certainly safer then typing your username and password everywhere all the time :)

In addition, newer YubiKeys allow for two different keys to be stored in them and will generate OTPs from one or the other based on how long the button is pressed. Toshio Kuratomi puzzled out the magic incantation required to write the second key and observed that holding the button for longer than 2.5 seconds would send an OTP based on the second key. Using that feature would allow sharing the device with two separate services, but if YubiKey OTPs become more popular, some other scheme for handling multiple sites will probably be required.

In some ways, this is all just a prelude to more widespread use of multi-factor authentication. In the next few years, OTPs are likely to become much more widely used for accessing sensitive sites and applications. The YubiKey idea is interesting, particularly because it doesn't require client-side support and doesn't lock users into some proprietary OS. A similar device that used public key, rather than symmetric, encryption would be worth trying as well.

Index entries for this article
SecurityAuthentication


to post comments

Fedora accepting YubiKey one-time passwords

Posted Oct 14, 2010 10:41 UTC (Thu) by loevborg (guest, #51779) [Link] (1 responses)

Very interesting, thanks for the article. I was wondering why more projects weren't taking advantage of OTP keys, which offer obvious benefits. YubiKey works with LastPass also. It would be interesting to know if this really improves the security - e.g. when logging in to your mail account in an Internet cafe (which normally is so insecure it almost hurts). In particular, it seems that it's possible to disable or circumvent the OTP requirement for logging in. What is the point of using it if it isn't made obligatory?

Fedora accepting YubiKey one-time passwords

Posted Oct 15, 2010 9:32 UTC (Fri) by salimma (subscriber, #34460) [Link]

Not making it compulsory makes it possible to recover from a lost YubiKey. As you suggested, the use case is thus to use the key's OTP when logging in from untrusted locations, and for high-security applications that demand it, and to use your normal password from computers you control, in the case that you forgot / lost your hardware key.

Fedora accepting YubiKey one-time passwords

Posted Oct 14, 2010 12:54 UTC (Thu) by itvirta (guest, #49997) [Link]

> One of the concerns raised was with the potential sharing of AES keys
> between servers. If a user wanted to use the same device with multiple
> YubiKey-enabled sites, they would need to share their AES key with all of
> the servers. If any one of those servers was compromised, it would allow an
> attacker to authenticate to any of the others.

Even worse, using the same key on multiple servers also allows a simple
replay attack where a valid login to server A is used afterwards to login
to server B. This works if both servers authenticate independently, since
the (monotonically increasing) serial number saved on B is not updated
when logging to A.

After reading the mail thread, it seems to me that the way out of this as
implemented by Fedora is that the user doesn't even know their AES key,
because the script writes it to the key automatically so they can't use
the same key elsewhere. That is, they don't say "don't do that, it's bad",
they say "it's ok because the script doesn't let you do that".

Anyway, don't do it, it's bad for you. :)

Opensource Android & Blackberry application for OTP authentication

Posted Oct 14, 2010 17:57 UTC (Thu) by gutschke (subscriber, #27910) [Link] (2 responses)

Requiring one hardware token per service can get cumbersome quite quickly. Fortunately for Android and Blackberry users, they can instead use the open source Google Authenticator project. This allows the use of a single mobile application for an arbitrary number of OTP enabled services:

http://code.google.com/p/google-authenticator/
market://search?q=pname:com.google.android.apps.authenticator

This is currently supported by (some) Google accounts and is available as a PAM module for use by any PAM-enabled system. That means, Linux users can easily enable OTP support for all their services.

I am the author of the sample PAM module, so feel free to ask questions in this thread.

Opensource Android & Blackberry application for OTP authentication

Posted Oct 15, 2010 9:49 UTC (Fri) by mfedyk (guest, #55303) [Link] (1 responses)

what keeps one rogue app from compromising the otp key?

Opensource Android & Blackberry application for OTP authentication

Posted Oct 15, 2010 17:13 UTC (Fri) by gutschke (subscriber, #27910) [Link]

Are you worried about rogue applications on Android? If so, that should not be an issue as applications are protected from each other by the Android security model.

You could conceivably have a rogue application that uses a bug in the Android system to elevate privileges. Yes, in that case, all bets are off. But in that scenario an attacker could conceivably do a lot more damage anyway (e.g. use your e-mail account to recover passwords to your bank account). You really are at the mercy of your handset manufacturer to release security updates before this becomes a problem.

And you are at the mercy of your Android market provider (typically Google) to hopefully catch rogue applications early on and to remove them from the market and/or to notify your phone to disable them.

But all of this is clearly outside of the scope of the OTP project.

Or maybe you are worried about rogue applications on the Linux machine having access to your PAM module. Yes, they do. But that's not any different from rogue applications having access to your SSH credentials or being able to install backdoor applications.

Linux is not designed to safely allow execution of arbitrary untrusted code. If an attacker can run arbitrary code as either a user or worse as "root", then they can easily subvert all security for that account.

Sandboxing protects against specific attack vectors (e.g. in hardening browsers against attacks), but sandboxing of arbitrary untrusted binaries is still a largely unsolved problem.

Having said all of this, OTP in general is a good way to introduce a second factor that makes attacks a lot more difficult. But it is never going to be a way to make attacks impossible.

At some point, you have to realize that if a legitimate user can access the system, then a sufficiently motivated and resourceful attacker will also be able to do so. Nothing will ever prevent that. Ultimately, "rubber-hose cryptography" (aka torturing your victim until they agree to log into the system for you) always works.

All we can hope for is making attacks so expensive and difficult that they become unattractive. OTP is a step in this direction.

Fedora accepting YubiKey one-time passwords

Posted Oct 15, 2010 10:46 UTC (Fri) by rwmj (subscriber, #5474) [Link] (1 responses)

It works really well for me:

http://rwmj.wordpress.com/tag/yubikey/

Now if only I could persuade my bank to use a OTP / secure key setup instead of the completely useless (and *actively* insecure) "Verified by Visa" system.

Fedora accepting YubiKey one-time passwords

Posted Oct 17, 2010 7:11 UTC (Sun) by sitaram (guest, #5959) [Link]

For people wishing they could use this for banking, this sort of device cannot prevent a complete MITM attack. Bruce Schneier is fond of saying that the server must validate the *transaction*, not the user. Yubikey can't do that because it can't incorporate any transaction info in the generated output.

The problem with doing that is form factor. The most convenient I have read about so far is the EMUE card -- haven't seen it in action anywhere, but it looks nice, and I'm sure there are others like it.

Fedora accepting YubiKey one-time passwords

Posted Oct 15, 2010 17:41 UTC (Fri) by joey (guest, #328) [Link] (1 responses)

"The key never touches the drive during the burning process [so the] attack window here, while real, is very tiny."

From looking at the script, that's not really true, since it does not lock its memory the key could be written to swap.

But that's a minor problem compared to the fact that the key is exposed for all local users to see in the parameters to the ykpersonalize program ...

Fedora accepting YubiKey one-time passwords

Posted Oct 27, 2010 12:53 UTC (Wed) by salimma (subscriber, #34460) [Link]

Local users with root access, I suppose. Which is why setting up the key on a public machine is not recommended :)


Copyright © 2010, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds