Yubico Forum

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

All times are UTC + 1 hour




Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Sat Feb 07, 2009 9:14 am 
Offline

Joined: Sat Feb 07, 2009 8:24 am
Posts: 3
The bug has been isolated…

This is a description of what occurs.
OTP replays are currently not detected within the same session when a YubiKey is inserted in the USB port. But if the key is removed and reinserted between OTP generations (as with most normal usage), then any old OTPs generated during earlier sessions cannot be replayed .

Example: If a user inserts a YubiKey, and generates OTP 1, OTP 2, OTP 3 and again replays OTP 1 and/or OTP 2 in the same key insertion session (i.e. without removing and reinserting the Yubikey) the replay is not detected and a positive authentication response is generated. However, if the user removes and reinserts the YubiKey in the USB port (most normal usage) and generates OTP4 and then try to replay any of OTP 1 through OTP 3, they will be detected as replay and a negative authentication response will be generated.

Key inserted first time
OTP1 (Accepted in any order within same key insertion)
OTP2 (Accepted in any order within same key insertion)
OTP3 (Accepted in any order within same key insertion)
Key removed

Key Inserted the second time
OTP4 (Once OTP4 is used - then any of the OTP 1 though 3 are detected as replay attacks)
Key removed

Key Inserted the third time
OTP5 (Once OTP5 is used - then any of the OTP 1 through 4 are detected as replay attacks)
Key removed

A fix has been identified and is currently being tested. More info to come after testing is complete.

Kurt L. Yubico Support.


Top
 Profile  
Reply with quote  

Share On:

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

PostPosted: Sat Feb 07, 2009 11:22 am 
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
This is a serious issue indeed and it is being fixed right now. It is certainly embarrassing and I understand everyone who gets upset that such a thing could happen.

I feel it is important to say that the current sever was initially designed as a "proof of concept" for trials and evaluation only. We were actually taken a bit by surprise that the service quickly became popular and that several people and organizations wanted to use it right away.

We have got several questions about availability/uptime, redundancy, security, physical protection, QA, auditing etc. and have therefore initiated the "next generation server" development project where we'll offer a premium service rather than just a "best effort" service. This service is targeted for launch at March 1st.

So we kindly ask everyone for a bit of patience. We'll ensure that this bug gets fixed now and keep your eyes open for the new service.

With the best regards,

Jakob E
Hardware- and firmware guy @ Yubico


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 07, 2009 5:55 pm 
Offline

Joined: Sat Feb 07, 2009 5:35 pm
Posts: 4
And the fix is just slapped in there, with no regression testing at all. And no new test cases. (See http://code.google.com/p/yubikey-server ... Tests.java)

How do you know that you're not opening up another can of worms? How do you have *any* idea that you've fully fixed the problem?

Looking at how changes are made, for example,
in http://code.google.com/p/yubikey-server ... svn34&r=32, with its commenting out of code to support new firmware while disintegrating older firmware + total absence of testing of the fix doesn't exactly inject a lot of confidence going forward.

Come on, you can do better!


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 07, 2009 9:25 pm 
Offline

Joined: Fri Feb 06, 2009 12:45 am
Posts: 5
The Yubikey idea is really great, I wouldn't be here otherwise. I love that its not costly and it is something even my wife could use. The fact that the software is open-source also gives you an advantage over other OTP products. That said, I would like to see the software side of things managed better and with more structure. I'm sure your resources are limited, but if we could have a mailing list or forum board dedicated to the development of the authentication server that would be great. If you setup a QA/test server I would be willing to help test fixes (and I'm sure others would as well). One benefit of your quick growth is that you will have a bigger community to help with fixes, testing, etc. Of course we will also find bugs and scrutinize as well. This is all good and can and should lead to a better product if you let it.

Again, my concern is not so much about the software, I can fix that. My concern is the stability of Yubico as a company. How is the company doing? Will you be around in 2,5,10 years? I could potentially be purchasing quite a few Yubikeys for clients, but I need to know I am not leading them down the wrong path. If Yubico is ever in danger it would be nice to have the hardware specifications for the Yubikey released openly. Anyway, these questions probably belong in the "Other Questions" board.

Thanks for looking into the issue. If we decide to go with Yubikeys I will make sure to contribute whatever I can to the software.

Thanks.
Ryan


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 07, 2009 10:59 pm 
Offline

Joined: Fri Jun 20, 2008 2:59 am
Posts: 84
I agree this is a big deal. But it ends up being a fast fix, so good. I hope yubico goes into detail about how similar issues will be prevented.

The yubikey hardware design is pretty outstanding and has proven very robust, and any applications that don't rely on the yubico internet server (or software) wouldn't even be affected by this issue.

So the sky isn't totally falling here, even though it's certainly true that this is a big and embarrassing issue to be found. Perhaps based on this 'unexpected success' of the service as described by Jakob, it would be time to institute some formal QA or some sort of validation process. But at least the problem is handled with grace, openness and expedience. An open source community can forgive a lot as long as the vendor continues to be an honest partner with us and diligently address concerns.

(Edited to reflect new info evening of Feb 7)


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 08, 2009 5:40 am 
Offline

Joined: Wed Jan 28, 2009 4:06 am
Posts: 3
I can confirm this issue. In January I posted these same findings to the Gibson Research Corporation NetNews system. I have been concerned is issue is fixed.


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 08, 2009 8:09 am 
Offline

Joined: Sat Feb 07, 2009 8:24 am
Posts: 3
Update on the fix that was applied.

The problem
The previous version did not properly detect OTPs generated within that same session where the Yubikey remains inserted in the USB slot. If the Yubikey was removed and then reinserted again and a new OTP is generated (most common use case) then OTPs from previous session were invalidated correctly and detected as replay attacks. However, for OTPs that were generated while the key remained inserted then OTPs within that session could be replayed without detection until next removal and insertion of the Yubikey. The reason was that the Yubikey counter for “session use” was not checked by the server.

The fix
A SessionUse variable was added and is now checked by the server in order to properly detect replays of OTPs within the same session where the Yubikey remains inserted while generating OTPs during the session.

The changes to the code can be reviewed following the links below.
http://code.google.com/p/yubikey-server ... tail?r=33#
http://code.google.com/p/yubikey-server ... tail?r=34#

Kurt L - Yubico Support


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 08, 2009 7:03 pm 
Offline

Joined: Sat Feb 07, 2009 5:35 pm
Posts: 4
But for an attacker it doesn't matter if the token is present, of course.

The original error seems to be the odd commenting out of OTP checking code in
http://code.google.com/p/yubikey-server ... =side&r=32

Any comments on that?


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 08, 2009 10:21 pm 
Offline

Joined: Fri Jun 20, 2008 2:59 am
Posts: 84
zzap wrote:
But for an attacker it doesn't matter if the token is present, of course.


Yubico people: The way you described this bug causes a lot of confusion because of this counter intuitive notion about sessions. You should clarify and remember that your users do not begin with an understanding of the internal details of your algorithms!

I am going to try re-stating the bug cases in a different way to see if it is any easier to understand. Please correct me if I'm wrong:

This bug has nothing to do with whether the key is plugged in at the time of attack. A more clear way to state it is: if you always follow the behavior to only generate one OTP at a time and then unplug your key, the OTPs you generate will never trigger the bug case in the service. Therefore, an attacker who has access to all those OTP strings will not find them at all useful, since they cannot cause the server bug.

But any time you generate more than one OTP while still leaving the key plugged in, then those OTPs are of a kind that could trigger the bug. An attacker who collects those OTPs could use one or more of them as valid in the future. Once you plug in and validate the real key again, that last attack window closes. It causes the replayable OTPs "expire" so to speak.

Anyway, all this will be moot with the fixed server code. I am only trying to help increase understanding about the nature and scope of the found bug.


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 10, 2009 4:44 pm 
Offline

Joined: Sat Feb 07, 2009 5:35 pm
Posts: 4
Not to harp on this, but I am concerned no one from Yubico bothers to address my concerns. Is there really no interest from Yubico's side in explaining why the source code changes were made in the way they were?


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

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 0 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