A synchronous password token has to operate at the same pace as the receiver. That is, the token has to advance to the next random number at the same time the receiver advances. Because of clock imprecision, the two units will not always be perfectly together; for example, the token's clock might run 1 second per day slower than the receiver's. Over time, the accumulated difference can be

significant. Suggest a means by which the receiver can detect and compensate for clock drift on the part of the token.

What will be an ideal response?

The
algorithm
for
SecurID
is
a
good
example
of
maintaining
synchronization.
Essentially,
if
the
token
presents
a
value
of
X,
the
receiver
compares
X
to
the
current
expected
value,
as
well
as
several
earlier
and
several
later
values.
If
any
of
these
matches,
the
receiver
resets
its
expected
value
to
the
matched
point.
The
receiver
also
checks
when
the
token's
and
receiver's
times
were
last
synchronized.
If
the
times
have
not
been
synchronized
recently
(that
is,
if
the
token
has
not
recently
been
used
for
authentication),
the
receiver
will
allow
greater
possible
drift
between
the
token's
and
receiver's
clocks.