How does SecurID work?

[CookingWithGas]

HowStuffWorks and other sites talk about how you use it, but not how it actually works.

Introduction: A SecurID token is a gizmo about 2.5 x 1.5 inches that has a 6-digit LCD display. It’s sole job is to generate numbers. A new 6-digit number appears about once a minute. You create a unique 4-digit PIN when you register. Each time you want to access the system, you enter your PIN plus whatever 6-digit number is showing at that moment. The authentication is what they call two-factor authentication, because you have a PIN plus you have to have the device in hand.

Q: How does it know that that the 6-digit number I typed in is authentic?

Here are my guesses, which I shoot down:

A. Subset. There are a million possible numbers, but only a certain subset of them are valid. There is no way to guess the subset, but the server on the other end knows which ones are valid for my device. Doesn’t seem reasonable, since it would have to generate a large number of numbers to prevent learning the entire subset by inspection. You could capture a million numbers in less than two years (not terriby practical but certainly feasible if you’re patient). OTOH there would have to be a small fraction of those million valid to avoid someone getting lucky by just guessing a number. For example, if 500K numbers were valid, you would have a 50/50 chance of guessing one.

B. Timing. Maybe the number that the device displays is synced with the server. I am skeptical that the clock in the device would be accurate enough for that, however. The device is standalone and never connects to anything to sync the clock. Even a very good quartz watch will lose or gain time, that would throw it off by more than a minute over a month or maybe a year.
B2. Timing on a larger scale. Maybe it changes what numbers are valid on a particular hour or day, rather than targeting the exact number displayed at a specific minute.

C. Sequence. The device surely uses some unpredictable (but not random) algorithm to produce the numbers, but you only enter a single number. So the server can’t compare two sequential numbers to see if they’re the right sequence. so that’s out.

I was thinking it might be similar to the technology used for remote car door openers, which is discussed in howstuffworks in some detail. However, that requires a more complicated protocol between the sender and receiver than just sending a single code, and I think is similar to C above.

Anybody know? I would even entertain educated guesses, but it would be nice if someone really knew.

[SmackFu]

It’s B. They have a patent on the method to deal with out-of-sync clocks (which I did not read all of): 4,885,778.

The principal object of the invention is to synchronize the generation of time-dependent non-predictable codes which are independently generated on the basis of date and time information which are generated on separate devices which over time may deviate out of time synchrony with each other.

[Schnitte]

Also see the SecurID website.

Each end user is assigned a token which generates a new, unpredictable code every 60 seconds.[…]Each RSA SecurID Authenticator has a unique symmetric key that is combined with a powerful algorithm to generate each new time-based code. Only the RSA® Authentication Manager knows which number is valid at that moment in time for that user/authenticator combination.

[Chronos]

A hunch: They have some known tolerances for how much the time on the unit can drift. Say, for instance, that over the lifespan of the device, it’s not expected to drift more than 10 minutes off of the correct time. Then, when you give your current code, the server compares it not only against its own current code, but also against the 10 previous codes and the 10 next codes. You could improve on it further, too: Every time that a code is entered, the server then knows (by seeing which code matched) how far off the clock in that unit is. If the device is used frequently, then it would probably only drift by a minute or two between uses, and the server would then only have to compare the current code against 3 or 5 server codes.

[SCSimmons]

@Chronos

A hunch: They have some known tolerances for how much the time on the unit can drift. Say, for instance, that over the lifespan of the device, it’s not expected to drift more than 10 minutes off of the correct time. Then, when you give your current code, the server compares it not only against its own current code, but also against the 10 previous codes and the 10 next codes. You could improve on it further, too: Every time that a code is entered, the server then knows (by seeing which code matched) how far off the clock in that unit is. If the device is used frequently, then it would probably only drift by a minute or two between uses, and the server would then only have to compare the current code against 3 or 5 server codes.

I can tell you this-it doesn’t seem to compare to any code but the current one. I’ve entered a code in the waning seconds before expiration, and if my connection is slow to establish, it arrives at the server too late & I get an invalid login error and have to log in again. (The display has a little countdown bar to let you know when the password is about to change, but sometimes you just want to challenge the network, right? )

[Schnitte]

But that would reduce the security level. The idea behind integrating time into the function that generates the passcodes is to increase security - a code a fraudster might have overheard quickly becomes worthless. Allowing for a longer time drift increases the possibilities crooks can exploit.

And determining the time by checking which code matched reduces security even further. It’s pretty much the way it ought to be reversed: The idea is to compute the one and only valid code for this moment, then check if the ode entered by the user matches. Setting the system-internal clock to the time for which the entered code would match is somehow the wrong way round.

I’m not saying this might not be what they’re doing; I just think it’s not such a clever idea. It would be better to use radio controlled clocks for the security token synchronized to the official master clock.

[JohnM]

I’ve used one for years, so I have some empiric evidence for how it handles time sync issues. If I haven’t used my card for a while (days/weeks), and I happen to enter the key when it is near the end of the countdown, then occasionally I will be asked to reauthenticate with a newly generated code. This tells me the system did check previous/next values to account for synchronization errors, but then makes me enter the next value. If what I entered is the correct value following the previously entered one, then the central server notes the time differential between server time and token time, and things go back to normal.

[gazpacho]

@Schnitte

But that would reduce the security level. The idea behind integrating time into the function that generates the passcodes is to increase security - a code a fraudster might have overheard quickly becomes worthless. Allowing for a longer time drift increases the possibilities crooks can exploit.

And determining the time by checking which code matched reduces security even further. It’s pretty much the way it ought to be reversed: The idea is to compute the one and only valid code for this moment, then check if the ode entered by the user matches. Setting the system-internal clock to the time for which the entered code would match is somehow the wrong way round.

I’m not saying this might not be what they’re doing; I just think it’s not such a clever idea. It would be better to use radio controlled clocks for the security token synchronized to the official master clock.

Sure it somehwat reduces the security to have 10 out of a million valid numbers at any one time. But it is not that much reduced. You still have to try a huge number of passwords every minute to try and brute force your way in.

[arrosen]

@gazpacho

Sure it somehwat reduces the security to have 10 out of a million valid numbers at any one time. But it is not that much reduced. You still have to try a huge number of passwords every minute to try and brute force your way in.

When I used SecurID, if I entered the code incorrectly 3 times, I had to wait until the card generated the next number. Therefore, it seems highly unlikely that a brute-force method of cracking the code would work.

[kanicbird]

I would assume it picks up the atomic clock info and resyncs its internal clock

[gazpacho]

The securids that I have seen are little keychain fob sized things that run off a watch battery that lasts for years and can be taken all over the world (pending goofy encryption regulation). They run for years on the watch battery. They are not resyncing to any radio signal.

[gotpasswords]

The tokens themselves don’t synch to anything. They just sit there displaying semirandom numbers every 60 seconds. The batteries are not replaceable and the tokens are not indestructable. They will succumb to hot cars in the Arizona sun, laundry and over-anxious TSA agents. (My co-worker’s token was wrecked at the airport by someone who was convinced that it was some sort of bomb timer because it was displaying a number.)

The semirandom number generation is based on a “seed” value that is related to the 8-digit serial number on the back of the token.

Based on the token’s serial number, the SecurID (aka ACE) server can calculate the sequence of numbers that will display on the token. The number generation is being done simultaneously by the token and the ACE server. AFAIK, the server is not perpetually doing this, but only calculates the expected tokencode when the user enters their ID and the servers recognizes that the user has a token. If the token’s internal timing drifts, the server asks for the next tokencode and adjusts its timing for that particular token. Once token and server are in sync, there’s a +/- one tokencode variance permitted. If the token drifts a bit, the user will get a “enter next TOKENCODE” prompt. If it gets really out of whack, there is a manual administrative function where the user reads off the codes and the help desk enters the codes into ACE.

Keeping the ACE server (and all other servers) synchronized to the same time is really important. One of our first troubleshooting steps when a server stops authenticating users is to confirm it’s got the right time.

Using UTC is often best as it completely steps around the “what time zone is that server in?” issue. At a minimum, you can point your servers to tick.usno.navy.mil or tock.usno.navy.mil for NTP (network time protocol) service.

As for widening the tolerance to allow one tokencode on either side of the expected tokencode, you have to make compromises when setting up security. If the system required split-second timing with no forgiveness, user acceptance will be nil. Even with that three-code tolerance, an intruder still has to hit that three in ten trillion chance of finding the right passcode for a given user ID. (Three attempts at finding the 8-digit PIN plus the 6-digit tokencode - if a user has a 4-digit PIN, it’s “padded” with four leading zeros.) Pretty good odds that they won’t hit it in three attempts, and then the ID (should be!) is locked.