Yubico Forum

Hi everyone,
I have some questions about how we should be using the values given to us when an OTP is decoded and parsed. Each OTP has, among other things, the following: a session counter, a "times inserted" counter, a low timestamp and a high timestamp.

Counters
Is it good enough to take the "times inserted" counter, shift it left, and add the session counter to get a "total counter" that we can keep track of in a database? Or should we be keeping these values separate?

Timestamps
Mostly the same question. If you shift the high timestamp left and add the low timestamp, then you get the entire timestamp, correct?

Random Values
My thought is that there's no need to keep track of this at all. It's merely used to add some entropy to the key before it is encrypted. The only time you have to worry about it is if you're performing the CRC.

Google Project
I started a project on Google Code, http://code.google.com/p/yubico-php-lib/. It is not meant to compete with Alex's project, it is merely a way to test different ideas.

Counters: Shifting insert counter left to combine with usage counter should work. The combined counter of the next decoded passcode should actually be higher than the combined counter of the previously decoded passcode. If it is not, then this would be a replayed password.

Timestamps: This runs at 8hz. If you are checking this, for correct issue time (plus/minus 10 seconds to account for internet lag), then you have to check just the insertion counter by itself in the process. That is, if insertion counter of current decoded passcode is higher than the insertion counter of last decoded passcode, then Store the current decoded timestamp, as well as the server side date/time. If the insertion counter of current passcode is the same as insertion counter of last decoded passcode, then subtract previously recorded server date/time from currently recorded server date/time, (converted to seconds.), and multiply that result by 8. Now subtract previously decoded passcode timestamp from current decoded passcode timestamp, and compare the results. (It should be plus/minus 10 seconds.) This is only really needed for high security applications.

Random Values: Only really there to add entropy to the encrypted result. Calculate the checksum and validate the whole block, before doing the previous two operations.

I agree with you on the counter, and that is how I'm implementing it in my code. I don't completely understand what you're saying with the timestamp though. Could you give an example of how an attack would work, and how the timestamp prevents the attack?

Lets say you keep your Yubikey always plug in your laptop.
Someone open notepad and press on the button.
it will generate a code and the bad guy take this to is computer (email, thumdrive, floppy...) and try to login from is desk with a valid OTP.
Since it was the next valid code. the authentification server will say valid OTP but ... the time stamp is not matching.

simply said the timestamp is for checking the time the button was press to the time it is send to the authentification server. too long is not good (an attack).

_________________
Patgadget
Montreal

Thanks for explanation, I think I understand it now. What does everything think is a good time? 10 seconds like caitsith6502 suggested sounds reasonable to me.

Testing for a 10s interval would be really nice. It should probably result in a particular error code, so that the web application can recover by asking for another yubikey OTP. If the next OTP is also bad, you should warn the administrator or something like that.

Thanks for your effort!

/Simon

i think that the bad guy could unplug and plug back the yubikey then press on the button.
The timer at that point have nothing to compare it to!
since there is no battery inside the yubikey, there is no way to prevent that but anyway at that point the guy have a physical access to the key witch is bad anyway.

_________________
Patgadget
Montreal

I agree with patgadet - since the Yubikey can be part of a multi-factor authentication system, it can be the "something you have" part. So if a bad guy has physical access to your yubikey, then all bets are off and you're toast. But that's the same if you have some other sort of security token. A good system should probably employ a user+password+yubikey.

That's true. However, a 10s-check catches the scenario where the attacker borrowed your yubikey for a few minutes, and generated a lot of OTPs and then returned the yubikey. This can be a feasible attack that doesn't take many seconds. Thus, a "best practice" for web sites that use yubikeys for sensitive stuff would be to require the user to authenticate several times and compare the time deltas. If the yubikey is removed and re-inserted (i.e., counter=0), ask for another OTP and compare time deltas.

This attack isn't the most important thing to spend time on fixing, IMHO, but for completeness this is what should be done.

/Simon

If you use a device with a battery then someone who gets a copy of the code sent to site A can not use it on site B (outside the few minutes in the time window).

It seems to me that if I was to use a Yubikey to authenticate to multiple sites, and if one of those sites was compromised or the key was captured in-flight then the attacker could use it to login to other servers.

For example let's say I want to login to two servers via ssh from an Internet cafe. Let's also assume that I don't want to have them talk to each other (maybe they are owned by different people - and even if they were owned by the same person there are reliability issues in getting multiple servers to talk to each other).

So if I use a Yubikey on machine A then an attacker could use the same key to immediately login to machine B. Now there is the option of using a password as well. But if I was to use the same Internet cafe on multiple occasions (or do something else that allows a hostile party to get the password) then they win.

Realistically, few people have a threat model that involves an attack of that complexity (for basic 0wnage the simpler attacks work well enough that the bad guys are kept busy and wealthy). Also for the case of ssh access a skilled attacker could own the terminal and take over a session once it was authenticated, fake a BSOD and make the user think that they just lost access. A few hours of access while the legitimate user thought that they were having technical problems could do a lot of damage.

Also even if a device using Yubikey technology (USB keyboard based) had a battery and included a time-stamp, this would not prevent an attacker from logging in to server B within a matter of seconds of me logging in to server A. So the battery backed keys that display a number are also vulnerable to the same attack. It seems that solving this properly (in a cryptographic sense) would require that the key receive a challenge from the server.

As the caps-lock light is used for sending data to the key, I wonder if (using hardware that is more advanced than the current Yubikey) it would be possible to have an enhanced mode of operation which uses the caps, scroll, and num lock lights to transmit 3 bits of data per baud to send a challenge from the server, that should allow sending a 32bit challenge in a small amount of time but would require client software to manipulate the LEDs.