Yubico Forum

How does the yubikey deal with a key a reuse attack?

For example:

I have a yubikey that I use to log into my local intranet, and at the same time I'm reusing the yubikey to log into openid enabled web sites out on the Internet. There is a sniffer (malware, network sniffer) that is capturing these keys. What prevents the malware from logging into my local intranet with the keys that it captured?

If your local intranet uses the Yubico server to authenticate the key it will receive status of REPLAYED_OTP if a previously used key is entered (instead of OK status). The server checks the Session Count and Session Use fields to verify that OPT is new. If your local intranet is doing the authentication and not saving and checking these fields, it is prone to a replay attack.

-Tom

Also, another consideration, is that the moment you use a new key, ANY and ALL previously captured keys, regardless of having been used or not, will give the REPLAYED_OTP response. This means if you think an attacker may have borrowed your yubikey for 5 minutes, to capure 50 OTPs, 10 per insert, you can invalidate 100% of these captures, therefore, either let yubico validate the key, or check all of the counters, and only accept keys that are newer than the previously played counter.

To be safe,
1 Yubikey, 1 authentification server.

_________________
Patgadget
Montreal

Thanks to all who replied.



I see. Let me explain why I'm asking this question in more detail. I am considering developing a solution based on the yubikey for windows based authentication, and one of the requirements of this system is to be able to log in offline. Therefore, you can't report every key use to any centralized server. Also, some clients of this solution might not want to trust another third party with their authentication and want to run their own server (which we will provide).

So now it seems to me that for any yubikey based system you need a centralized authentication server. So as a fictitious example, you won't be able to use the same yubikiey securely to log into an OpenID enabled web site, log into your computer, and perhaps log into a forum using the same AES key.

So really, and this goes back to what patgadget said, for each authentication provider that you want to use securely you need 1 yubikey and the authentication provider must be centralized.

Am I correct in this assessment?

I thought of this, but I believe it would only work if you as the centralized server are aware of all uses of that particular yubikey. The second you have two authentication providers per AES key, or a non-centralized solution, the attacker could capture an OTP from the second provider and submit it to the first, and it would be valid because the first provider is not aware of the session/use count incrementing with the second provider. Also, this is assuming the user does not just pop open notepad and start hitting the yubikey button just for kicks, and they happen to be infested by malware. So in a perfect world where you can keep track of all uses of the yubikey OTPs you can then keep track of them and invalidate them.

Good discussion on an important topic,

We all encourage implementations to be validated to one server only (it does not need to be our own) for a few reasons:

- Keeping track of counters and as mentioned earlier in the thread, properly detect potential replay attempts. If several servers are to share keys, a certain "band" of accepting potential replays has to be accepted. Furthermore, no real information can be gained if lots of OTPs are lost. A single server can detect this as some form of misusage.

- Minimizing the spread of symmetric keys. As we all know, a symmetric key that is not held tight can destroy for others. We beleive it is a legal nightmare to sort out who-has-compromised-the-key issues

- Revoking of a key is simpler

We beleive that sharing Yubikeys between multiple services is best done through one single validator (which we hope there will be thousands of in the future). That validator is typically the one issuing the key. Other sites can then as that particular validator to validate an OTP.


Another feature to prevent OTP harvesting and Phishing is to use the timestamp field to calculate the delta between two generated OTPs. In a scenario where a bigger stake is at risk, the server would typically ask for one OTP when the user logs on and a second when "checking out". The server knows the exact time delta between the OTPs but the Phisher doesn't.

Regards,

JakobE
Hardware- and firmware guy @ Yubico

Very good point about the timestamp, I didn't think of that. That adds a whole new order of magnitude in terms of difficulty perpetrating this attack.

Thank you for the response.

I am not sure of the robustness of the advices I am about to give, but here they are...

For critical actions within an application, it is good practice to re-authenticate the user and log the time of the action (Yubikey make this a breeze as long as you take care of the focus to the yubikey code field for the user).

You can use the time difference suggested above to ensure no harvesting of passcode was done. This might also protect your app against XSRF (http://en.wikipedia.org/wiki/Cross-site_request_forgery) for these critical actions.

If the client host is compromized, it is also possible to intercept the passcode and freeze the browser/client before submission into the encrypted channel (This is true for any token based solution). The above advice might still apply but a separate channel is probably preferable, (i.e. SMS confirmation...).

---
> Another feature to prevent OTP harvesting and Phishing is to use the timestamp field to calculate the delta between two generated OTPs. In a scenario where a bigger stake is at risk, the server would typically ask for one OTP when the user logs on and a second when "checking out". The server knows the exact time delta between the OTPs but the Phisher doesn't.
---

I'm not sure I understand this. Could someone please elaborate?
Please assume, tokens would be unplugged/plugged for logon/logoff.

The timer is reset to a non-zero value each time, right?