Security Token Questions

I do business with a company that issues a security token, that when used with a password, allows access to my account. I know it works and has worked for years, but I was curious as to how it works:

The number the token generates changes every minute or so, so knowing the number it generated a minute ago and the users password is of no value unless used while the number is valid. My questions are:

How do they synchronize the timing of the token with that of the server that receives it?

Since the token is good for several years before needing to be replaced, how do they synchronize the generated number with the server?

I know this is an electronics newsgroup, but I thought if anyone knew the answer to my questions, it would be here.

Reply to
Ken
Loading thread data ...

The software does not accept only a single reply, but rather accepts the numbers generated by the token at a range around the current time. When you enter a code that was valid a minute ago, it does not reject it but it accepts it and notes that the time in the token is apparently a minute behind. The next time you use the token the range of time has been shifted by a minute. This way the server "locks" to the drifting time of the token. When you would not use it for a very long time it could have drifted outside of the range, but in practice this does not happen (the clock in the token is accurate enough).

Reply to
Rob

Take a look at writeups (e.g. Wikipedia) for TOTP (Time-based One-Time Password).

To sum it up: the token dongle has its own time reference driven by a stable oscillator (typically something like a watch-crystal). The token's time is synchronized initially when it's first set up. It can of course drift over time (initial tolerances, aging, temperature, and so forth) just as a digital watch does.

The one-time password algorithm generates a unique password on a fairly coarse time scale - e.g. once a minute. The server will typically accept the validity of an OTP for longer than this e.g. for an additional 30 seconds or a minute on either side of the "nominal" minute. This allows for some amount of clock drift.

To deal with larger amounts of clock drift, the server can be 'adaptive'. That is, if it is offered a password which is (e.g.) "5 minutes out of date" or "5 minutes early", it may refuse it, but ask the user to try again in another minute. If it receives several one-minute passwords in a row, which are all valid but all "late" or "early" by the same amount, the server can conclude that the token-generator is valid but that its internal clock has drifted by this amount. The server could then store the time offset along with the token generator's ID - essentially resynchronizing itself with the token generator.

A somewhat similar technique is often used for "rolling code" security remote controls (e.g. car or garage door openers). If you accidentally activate such a device while it's in your pocket, it can "waste" a bunch of codes, and the car/garage receiver will still be expecting a code that has already been used up. In order to resynchronize you can push the remote button several times... a smart receiver will detect a valid sequence of codes coming from a "later" point in the sequence it was designed to accept, and will resynchronize.

Reply to
Dave Platt

Very clever way of compensating for a time difference. Then are the codes in all similar devices the same with respect to their code sequence, just that each device started the sequence at a different time??

Reply to
Ken

Nope, not in the general case. Each individual device (or each instance of a token-generating application on e.g. a smartphone) has an individual secret (or secrets, if it's generating one-time passwords for multiple services).

The service knows the secret for each device.

The one-time passwords (codes) are generated by a deterministic process, which takes as input the time and the device secret. This process is designed to be cryptographically strong... it's infeasible to predict what one code will be, based on its predecessors, unless you know the correct shared secret. It's also infeasible to "compute back" and figure out the shared secret even if you know a large number of the OTP codes that have been generated.

Thus, if you have two OTP generators, both generating codes for the same service (for e.g. two different user-IDs), and both happen to show a code of 123456 in this minute, it is extremely unlikely that they'll display the same codes during the next minute.

You can, however, program two or more OTP generators with the same shared secret, if you choose. For example, if you own a smartphone and a tablet, you can sign up with a service that offers one-time-code access, get your secret (some services deliver it as a scannable barcode or QR code), and load the secret into an OTP-generating app on both devices. These devices will then generate the same code sequences and you can use either to authenticate.

The TOTP algorithm is standardized, so you can use different OTP-generating dongles or apps based on a single shared secret, and they'll all interoperate.

Different devices/apps can store their secrets differently. For example, as I understand it, the Google Authenticator app for Android stores the secrets in a smartphone's internal hardware-backed keystore, and won't ever export them or back them up to a server. If you lose or wipe the phone, all of the secrets are gone for good.

Other apps (e.g andOTP) store the secrets in the device's flash memory, encrypted with a password that you must enter to use the app. andOTP will allow you to export the secrets via email (after encrypting them with a PGP key of your choice for security), and then re-import them into a different phone or tablet.

Reply to
Dave Platt

Tuning fork and watch quartz crystal oscillators out of fashion. The better dongles use a MEMS RTC (real time clock) that has built in temperature compensation via a lookup table. Drift is negligible:

I have a PayPal card by VeriSign, using OATH HOTP v2.1 that is crammed into a credit card size sandwich with no lumps.

More than you probably wanted to know:

"TOTP: Time-Based One-Time Password Algorithm"

"HMAC-based One-time Password algorithm"

"HOTP: An HMAC-Based One-Time Password Algorithm"

The authentication server does store the time offset. The real question is how big a time step window does it allow for drift. RFC6238 recommended time step is 30 seconds. All 4 of my key fobs are set to 60 seconds. "Validation and Time-Step Size" However, I've seen a few that are setup with absurdly long time steps. My guess(tm) is the vendor doesn't want to deal with irate customers who's cheap dongle suddenly doesn't work because of drift. In the systems I've looked at, the server pre-calculates 2 previous and 2 later codes, all of which it will accept as valid. Sometimes it will ask for the next code as a double check. With a 60 second time step, these codes give a +/-4 minute window, which more than enough to deal with any clock drift.

--
Jeff Liebermann     jeffl@cruzio.com 
150 Felker St #D    http://www.LearnByDestroying.com 
 Click to see the full signature
Reply to
Jeff Liebermann

That works, but only when the device has accurate time synchronization by another method. E.g. NTP. If not, the times on the two devices will differ, and the algorithm in the server that tracks the time offset will fail.

Reply to
Rob

Big fun when there is only a slight concentration of helium in the air!

Reply to
Rob

Yep, but it wasn't so "slight". The leak was about 120 liters of liquid helium, which expands into 90,000 liters (or 90 cubic meters, or 3,200 cubic feet) of helium gas. A typical MRI machine holds about

1,700 liters of liquid helium: Incidentally, 90 cubic-meters at $7.57/cubic-meter = $681

"iPhones Are Allergic to Helium"

Notice the size of the chip on the fingernail in the photo:

--
Jeff Liebermann     jeffl@cruzio.com 
150 Felker St #D    http://www.LearnByDestroying.com 
 Click to see the full signature
Reply to
Jeff Liebermann

That was the incident that made this wellknown, but others have tried to replicate it and found it doesn't require nearly that high a concentration! For example, see the youtube movie on the Applied Science channel:

formatting link

Reply to
Rob

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.