Security Token Questions

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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.

Re: Security Token Questions
Quoted text here. Click to load it

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).

Re: Security Token Questions
Quoted text here. Click to load it

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

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.

Re: Security Token Questions
Dave Platt wrote:
Quoted text here. Click to load it
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??

Re: Security Token Questions

Quoted text here. Click to load it

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.

Re: Security Token Questions
Quoted text here. Click to load it

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.

Re: Security Token Questions
On Thu, 19 Sep 2019 11:08:03 -0700, (Dave
Platt) wrote:

Quoted text here. Click to load it

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"

Quoted text here. Click to load it

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
150 Felker St #D
We've slightly trimmed the long signature. Click to see the full one.
Re: Security Token Questions
Quoted text here. Click to load it

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

Re: Security Token Questions

Quoted text here. Click to load it

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
150 Felker St #D
We've slightly trimmed the long signature. Click to see the full one.
Re: Security Token Questions
Quoted text here. Click to load it

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

Site Timeline