Fedora accepting YubiKey one-time passwords
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:
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 | |
---|---|
Security | Authentication |
Posted Oct 14, 2010 10:41 UTC (Thu)
by loevborg (guest, #51779)
[Link] (1 responses)
Posted Oct 15, 2010 9:32 UTC (Fri)
by salimma (subscriber, #34460)
[Link]
Posted Oct 14, 2010 12:54 UTC (Thu)
by itvirta (guest, #49997)
[Link]
Even worse, using the same key on multiple servers also allows a simple
After reading the mail thread, it seems to me that the way out of this as
Anyway, don't do it, it's bad for you. :)
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: 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.
Posted Oct 15, 2010 9:49 UTC (Fri)
by mfedyk (guest, #55303)
[Link] (1 responses)
Posted Oct 15, 2010 17:13 UTC (Fri)
by gutschke (subscriber, #27910)
[Link]
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.
Posted Oct 15, 2010 10:46 UTC (Fri)
by rwmj (subscriber, #5474)
[Link] (1 responses)
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.
Posted Oct 17, 2010 7:11 UTC (Sun)
by sitaram (guest, #5959)
[Link]
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.
Posted Oct 15, 2010 17:41 UTC (Fri)
by joey (guest, #328)
[Link] (1 responses)
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 ...
Posted Oct 27, 2010 12:53 UTC (Wed)
by salimma (subscriber, #34460)
[Link]
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
Fedora accepting YubiKey one-time passwords
Fedora accepting YubiKey one-time passwords
> 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.
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.
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".
Opensource Android & Blackberry application for OTP authentication
market://search?q=pname:com.google.android.apps.authenticator
Opensource Android & Blackberry application for OTP authentication
Opensource Android & Blackberry application for OTP authentication
Fedora accepting YubiKey one-time passwords
Fedora accepting YubiKey one-time passwords
Fedora accepting YubiKey one-time passwords
Fedora accepting YubiKey one-time passwords