At work, years ago, I used to have a key-fob device that was about the size of a thumb-drive. It had a 4 digit LCD screen that the numbers changed every 60 seconds. When logging onto certain servers, after entering my user ID and password, it would prompt me for the 4 digit passcode.

Now the key-fob was so small, I wonder how the process handled time drift. Especially 15 years ago.

Possible ideas how this may work I came up with in my mind, not being too smart about such marvels:

  • The manufacturer is certain enough that the battery will last long enough, and the key-fob would stand up to dropping, being bashed in pockets/purses
  • The token has an atomic clock receiver in it to sync up every so often
  • When the server receives the token, it looks to seen when it last sent out that particular 4-digit code, and if it was "recently" (say within 15 seconds or so) it would say "okay"

But I doubt any of those are right. Any ideas how that was handled? I was always nervous about using a number that was about ready to expire. I don't remember if I had to push a button on the key-fob to get a code. I do remember it being fairly unreliable; worked about 80% the first try.

  • And feel free to correct/add the magic tag that describes the "key-fob" device class. Aug 5 '20 at 23:37

You miss one synchronization strategy:

If it's used semi-regularly (e.g. every few weeks), you only have to account for the amount of drift that can happen in a few weeks. Whenever you use a code, based on time and a secret key, to log in, the server first checks the accurate time code.

If the code for now doesn't match, it can trivially generate one cycle in to the future, and one into the past. If either of these match, we can be fairly certain that the clock of the token has drifted over a threshold. This fact is stored, as a offset. If the token is sending back replies that is 60 seconds late, we store that, and next time we try with that as the baseline.

Lather, rinse, repeat if token continues to drift. It does not allow huge drifts, but based on the number of codes in the past or future you accept, you can accommodate for as much drift as you need. It will weaken security a tiny bit.

Wikipedia says cheap quartz clocks approach 6ppm accuracy. Thus, we can expect them to be within 60 seconds of the server for at least 115 days. If we check two codes backwards and forwards, it can go for well over 200 days.

The allowed time window may be made as large as desired, perhaps based on last use, to allow for clock skew.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.