Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Security Token Questions
38 views
Skip to first unread message
Ken
Sep 19, 2019, 12:36:09 PM9/19/19
to
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.
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.
Rob
Sep 19, 2019, 1:18:23 PM9/19/19
to
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).
Dave Platt
Sep 19, 2019, 2:08:55 PM9/19/19
to
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.
Ken
Sep 19, 2019, 2:38:16 PM9/19/19
to
codes in all similar devices the same with respect to their code
sequence, just that each device started the sequence at a different time??
Dave Platt
Sep 19, 2019, 3:11:59 PM9/19/19
to
In article <qm0hul$8h5$1...@dont-email.me>, Ken <K...@invalid.com> wrote:
>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??
Nope, not in the general case. Each individual device (or each
>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??
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.
Jeff Liebermann
Sep 19, 2019, 6:14:06 PM9/19/19
to
On Thu, 19 Sep 2019 11:08:03 -0700, dpl...@coop.radagast.org (Dave
Platt) wrote:
>To sum it up: the token dongle has its own time reference driven by a
>stable oscillator (typically something like a watch-crystal).
Tuning fork and watch quartz crystal oscillators out of fashion. The
Platt) wrote:
>To sum it up: the token dongle has its own time reference driven by a
>stable oscillator (typically something like a watch-crystal).
better dongles use a MEMS RTC (real time clock) that has built in
temperature compensation via a lookup table. Drift is negligible:
<https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator>
I have a PayPal card by VeriSign, using OATH HOTP v2.1 that is crammed
into a credit card size sandwich with no lumps.
<http://blog.agm.me.uk/blog/uploaded_images/PayPaySecurityKey-706729.jpg>
More than you probably wanted to know:
"TOTP: Time-Based One-Time Password Algorithm"
<https://tools.ietf.org/html/rfc6238>
"HMAC-based One-time Password algorithm"
<https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_algorithm>
"HOTP: An HMAC-Based One-Time Password Algorithm"
<https://tools.ietf.org/html/rfc4226>
>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.
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"
<https://tools.ietf.org/html/rfc6238#section-5.2>
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 je...@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
Rob
Sep 20, 2019, 7:57:52 AM9/20/19
to
Dave Platt <dpl...@coop.radagast.org> wrote:
> 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.
That works, but only when the device has accurate time synchronization
> 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.
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.
Rob
Sep 20, 2019, 7:58:51 AM9/20/19
to
Jeff Liebermann <je...@cruzio.com> wrote:
> 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:
> <https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator>
Big fun when there is only a slight concentration of helium in the air!
> 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:
> <https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator>
Jeff Liebermann
Sep 20, 2019, 7:49:47 PM9/20/19
to
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:
<https://www.usgs.gov/centers/nmic/helium-statistics-and-information>
<https://prd-wret.s3-us-west-2.amazonaws.com/assets/palladium/production/s3fs-public/atoms/files/mcs-2019-heliu.pdf>
Incidentally, 90 cubic-meters at $7.57/cubic-meter = $681
"iPhones Are Allergic to Helium"
<https://www.ifixit.com/News/iphones-are-allergic-to-helium>
Notice the size of the chip on the fingernail in the photo:
<https://www.sitime.com>
Rob
Sep 21, 2019, 6:18:27 AM9/21/19
to
Jeff Liebermann <je...@cruzio.com> wrote:
> On 20 Sep 2019 11:58:48 GMT, Rob <nom...@example.com> wrote:
>
>>Jeff Liebermann <je...@cruzio.com> wrote:
>>> 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:
>>> <https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator>
>
>>Big fun when there is only a slight concentration of helium in the air!
>
> 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:
> <https://www.usgs.gov/centers/nmic/helium-statistics-and-information>
> <https://prd-wret.s3-us-west-2.amazonaws.com/assets/palladium/production/s3fs-public/atoms/files/mcs-2019-heliu.pdf>
> Incidentally, 90 cubic-meters at $7.57/cubic-meter = $681
>
> "iPhones Are Allergic to Helium"
> <https://www.ifixit.com/News/iphones-are-allergic-to-helium>
That was the incident that made this wellknown, but others have tried
> On 20 Sep 2019 11:58:48 GMT, Rob <nom...@example.com> wrote:
>
>>Jeff Liebermann <je...@cruzio.com> wrote:
>>> 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:
>>> <https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator>
>
>>Big fun when there is only a slight concentration of helium in the air!
>
> 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:
> <https://www.usgs.gov/centers/nmic/helium-statistics-and-information>
> <https://prd-wret.s3-us-west-2.amazonaws.com/assets/palladium/production/s3fs-public/atoms/files/mcs-2019-heliu.pdf>
> Incidentally, 90 cubic-meters at $7.57/cubic-meter = $681
>
> "iPhones Are Allergic to Helium"
> <https://www.ifixit.com/News/iphones-are-allergic-to-helium>
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: https://www.youtube.com/watch?v=vvzWaVvB908
0 new messages