Yubico Forum

Re: Questions about the OTP

2008-10-20T12:16:44+01:00

Russell Coker wrote:

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.

Right, and two ways to combat that would be to use two-factor authentication (a password) and design the web page so that it requires multiple OTPs in order to do important operations. When you get multiple OTPs, you can compare times between them, to detect passive attackers.

Quote:

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.

Yeah, there are limitations to what we can do, but our target is to do something simple that is "good enough" for many purposes.

Quote:

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.

Yup, we have thought of that and _many_ other ways to do a platform-independent challenge/response mechanism, but we haven't come up with a good solution... Yet.

The problem with caps/etc-lock light is that it isn't cross-platform: Mac OS X treat each USB keyboard attached to it as separate devices, with their own caps lock etc status. In other words, pressing caps-lock on one keyboard doesn't change the light on other keyboards. I understand X.Org will change to similar mode in the future, because it allows the operating system to control each keyboard separately (i.e., you can have one US keyboard and one Swedish keyboard both working at the same time).

We may eventually do a YubiKey that can accept a challenge via a USB HID command, but it will require client software on the host computer. Writing it for Windows, Mac OS X, Linux etc will be possible, but it isn't as neat and convenient as the YubiKey is today. You probably will need some kind of admin capability on the machine as well.

/Simon

Statistics: Posted by Simon — Mon Oct 20, 2008 12:16 pm

Re: Questions about the OTP

2008-09-21T05:47:44+01:00

Simon wrote:

jwoltman wrote:

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.

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.

Statistics: Posted by Russell Coker — Sun Sep 21, 2008 5:47 am

Re: Questions about the OTP

2008-06-16T11:22:08+01:00

jwoltman wrote:

patgadget wrote:

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.

Statistics: Posted by Simon — Mon Jun 16, 2008 11:22 am

Re: Questions about the OTP

2008-06-16T06:41:09+01:00

patgadget wrote:

Statistics: Posted by jwoltman — Mon Jun 16, 2008 6:41 am

Re: Questions about the OTP

2008-06-16T02:37:23+01:00

Statistics: Posted by patgadget — Mon Jun 16, 2008 2:37 am

Re: Questions about the OTP

2008-06-15T23:58:05+01:00

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

Statistics: Posted by Simon — Sun Jun 15, 2008 11:58 pm

Re: Questions about the OTP

2008-06-14T23:36:38+01:00

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.

Statistics: Posted by jwoltman — Sat Jun 14, 2008 11:36 pm

Re: Questions about the OTP

2008-06-13T17:34:45+01:00

Quote:

Could you give an example of how an attack would work, and how the timestamp prevents the attack?
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).

Statistics: Posted by patgadget — Fri Jun 13, 2008 5:34 pm

Re: Questions about the OTP

2008-06-13T13:51:27+01:00

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?

Statistics: Posted by jwoltman — Fri Jun 13, 2008 1:51 pm

Re: Questions about the OTP

2008-06-13T07:07:36+01:00

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.

Statistics: Posted by caitsith6502 — Fri Jun 13, 2008 7:07 am

Questions about the OTP

2008-06-13T03:49:34+01:00

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.

Statistics: Posted by jwoltman — Fri Jun 13, 2008 3:49 am