Yubico Forum

...visit our web-store at store.yubico.com
It is currently Tue Jan 30, 2018 1:23 pm

All times are UTC + 1 hour




Post new topic Reply to topic  [ 11 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Reuse Attack
PostPosted: Wed Jun 11, 2008 7:28 pm 
Offline

Joined: Wed Jun 11, 2008 7:21 pm
Posts: 4
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?


Top
 Profile  
Reply with quote  

Share On:

Share on Facebook FacebookShare on Twitter TwitterShare on Tumblr TumblrShare on Google+ Google+

 Post subject: Re: Reuse Attack
PostPosted: Wed Jun 11, 2008 8:03 pm 
Offline

Joined: Fri Jun 06, 2008 10:58 pm
Posts: 6
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


Top
 Profile  
Reply with quote  
 Post subject: Re: Reuse Attack
PostPosted: Thu Jun 12, 2008 2:16 am 
Offline

Joined: Mon Jun 09, 2008 6:12 pm
Posts: 19
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Reuse Attack
PostPosted: Thu Jun 12, 2008 12:06 pm 
Offline

Joined: Mon May 26, 2008 5:16 am
Posts: 27
To be safe,
1 Yubikey, 1 authentification server.

_________________
Patgadget
Montreal


Top
 Profile  
Reply with quote  
 Post subject: Re: Reuse Attack
PostPosted: Thu Jun 12, 2008 1:39 pm 
Offline

Joined: Wed Jun 11, 2008 7:21 pm
Posts: 4
Thanks to all who replied.

patgadget wrote:
To be safe,
1 Yubikey, 1 authentification server.


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?


Top
 Profile  
Reply with quote  
 Post subject: Re: Reuse Attack
PostPosted: Thu Jun 12, 2008 1:46 pm 
Offline

Joined: Wed Jun 11, 2008 7:21 pm
Posts: 4
caitsith6502 wrote:
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.


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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Reuse Attack
PostPosted: Thu Jun 12, 2008 7:35 pm 
Offline
Site Admin
Site Admin

Joined: Wed May 28, 2008 7:04 pm
Posts: 263
Location: Yubico base camp in Sweden - Now in Palo Alto
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


Top
 Profile  
Reply with quote  
 Post subject: Re: Reuse Attack
PostPosted: Tue Jun 17, 2008 1:05 am 
Offline

Joined: Wed Jun 11, 2008 7:21 pm
Posts: 4
JakobE wrote:
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Reuse Attack
PostPosted: Mon Jun 30, 2008 10:43 pm 
Offline

Joined: Mon Jun 30, 2008 10:15 pm
Posts: 2
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...).


Top
 Profile  
Reply with quote  
 Post subject: Re: Reuse Attack
PostPosted: Fri Aug 01, 2008 5:34 pm 
Offline

Joined: Fri Jul 11, 2008 8:30 pm
Posts: 8
---
> 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?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group