4

Considering hardware tokens implementing OATH TOTP (c.f. RFC6238), it is common knowledge that the clock in such tokens drift. A token that is not used very often is likely to drift way beyond the synchronisation window that an authentication server is using, hence resynchronisation may be required.

A simple form of resynchronisation is simply to widen the search window, and this may probably work in most cases. But if the search window is too large, there is a small risk that the token is wrongly synchronised (assuming an OTP is repeated). I have not done the math, but this is probably rare.

I have heard about resynchronisation methods that take a sequence of OTPs to resynchronise. This would give an accurate resynchronisation of course, but at the expense of having the user wait for two or three OTPs.

I know some token and authentication service providers have implemented a method where the user can get partial information about the clock in the display, so that the time information + OTP is used as input to the resynchronisation process.

I have not seen any of the OATH RFCs giving a concrete recommendation for how to resynchronise. I wonder if anyone on this forum knows of commonly used methods in the industry; in particular what is your view on the last variant I describe?

  • Can you speak to how predictable the extent of drift is provided the static time of assembly/manufacture for a particular model's internal clock? I'm curious to know whether this variable could be used to automate the resynchronization process and keep a narrow search window. – AJAr Sep 24 '15 at 7:27
  • @AJAr, no I cannot unfortunately. For the solution I have in mind, tokens may come from different manufacturers. Given details on the expected drift in the tokens, it is possible to have some automatic resynchronisation (i.e. growing the window slightly if the token has not been validated for a long time). The RFC has some discussion of this in section 6. – Emil Sep 24 '15 at 9:10
1

You already mentioned the version I know for about 5 or 6 years and which is also implemented in privacyIDEA for resyncing TOTP tokens.

We are using two TOTP values to search for those OTPs in a larger window back and forth (The clock of the hardware token could go quicker and slower) When searching backward, you should of course not search for values older than those already used for authentication.

When looking at the HOTP spec, you can deduce this behaviour, since TOTP is just an HOTP with another counter type: It is recommended to use a sequence of OTP values.

In addition to the normal time drift adjust in your one or two minutes (2 or 3 time slices) you could to an auto resynchonization. If the OTP value does not match during authentication, you can save this value. If the user tries to login again (with the next value) you can use the old OTP value and the current OTP value to perform a synchronization the the bigger time window. This way you can use TOTP even for rare-2FA-users.

|improve this answer|||||
  • Asking for several consecutive OTPs is not very user friendly for TOTP IMHO, where tokens typically have time step sizes of 30 seconds or longer. But I like the idea of storing one or more previous OTPs to help resynchronising the token! – Emil Oct 14 '15 at 21:11
  • You are totally right. Manual resynchronization then takes looooooong 30 seconds. But nevertheless it does not hurt to have both possibilities - automatic resnyc and manual resync. – cornelinux Oct 15 '15 at 7:00
2

Usually, the TOTP server is configured with an NTP server for accurate time. Each time the token authenticates to the server, the server adjusts for the drift of the token. As you have mentioned if a token is not used often, the amount of drift can surpass the synchronization window.

To solve this problem most of the time, TOTP servers provide a re-sync option. For example, using a software from the TOTP service provider installed on the user machine can allow the token to obtains the server time and re-sync its clock.

Here are some links to shows examples of the re-sync option

http://support.nordicedge.com/nsd1326-how-to-re-synchronize-oath-tokens-with-oathresyncwebapp/

https://kc.mcafee.com/corporate/index?page=content&id=KB76278

Some other TOTP service provider will do it manually through a help desk like http://www.mideye.com/support/users/token-card-users/

Of course, there are some other methods, but in general, all of them allow one way or another the token to know the server clock.

|improve this answer|||||
  • That will work for TOTP apps on mobiles, desktops etc. but what about TOTP tokens as dongles? – Emil Sep 24 '15 at 9:12
  • I do not have experience with hardware TOTP token. The hardware tokens I used in the past were HOTP. They are event based and they can very easily get out of sync. a common approach to re-sync them is based on two variables inner otp window and outter otp window. See the answer crypto.stackexchange.com/questions/839/… – Ubaidah Sep 24 '15 at 10:25

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.