TOTP Hardware tokens with time sync feature

The TOTP scheme requires hardware tokens to have real-time clocking capability by embedding an oscillator in the device. A token’s clock drift needs to be considered and accommodated accordingly by the server. The protocol also advises the server to implement “look-ahead” and “look-behind” windows to for resynchronization when a tolerable amount of clock drifts have happened on the token.

While this is less critical with mobile authenticator apps (because mobile devices get their system clock synced via the cellular network or internet), all TOTP hardware tokens have a natural tendency to introduce time-drift after some period. This a well-known limitation of most oscillators, also mentioned in the RFC 6238: #6, and therefore the authentication server must be able to cope with the potential time-drift with TOTP tokens in order to minimize any impact on users. While most of the servers are ready to follow this recommendation (such as Azure MFA server which does this automatically, or TOKEN2 TOTPRadius where time drift can be set manually), there are many implementations where this recommendation is neglected. The average time drift for TOTP hardware tokens is and always was around 2 minutes per year or even more (according to some manufacturers, even 1 second per day is not something unusual).

After a period of time (i.e. 1–2 years) many of the tokens will drift outside the global synchronization window. While this has not changed a lot for the last 20 years, the battery life of modern tokens is now much longer. So, in the past, a hardware token battery lasted for 2 years and the maximum time drift introduced would be only 4 minutes. Now there are tokens with batteries good enough to work for over 5 years, which means that after its 4th year, even though the battery is still good to allow using the token for another year, the token cannot be re-enrolled to a different authentication server as its time drift would be almost 10 minutes and very few systems would support such big discrepancy. A token that is not used very often is likely to drift even more beyond the synchronization window that an authentication server is using. In addition, organizations are afraid to keep a large stock of hardware tokens: a token that is not used at all will have its battery almost like new, but the time-drift will not allow using the token at all, which causes such investments to be completely unprotected. While TOTP as an authentication protocol is secure and very easy to implement, the issue described above is seen as one of the main disadvantages, at least as far as hardware tokens are concerned.

To address the issue above, TOKEN2 has developed a solution that allows syncing the clock of hardware tokens using a special app (iPhone, Android and Windows versions are available). Changing the time on a hardware token is not as simple as adjusting your wristwatch: there is a potential security risk (TOTP code replay attack) if it is only the system clock that is being changed. The code replay attack is quite easy to explain. Imagine a user being under attack and the attacker has access to the hardware token, even for a few minutes only. If we allow changing the time only, the attackers can set the time in the future and write down the OTP code the token generates. 

This process can be repeated a significant number of times, so the attacker would have, let’s say, 100 OTP codes that the victim’s token will display at certain times in the near (or far) future. This already means that the second factor is compromised and is equal to attackers having the tokens shared key/seed. Once this has been achieved, the attackers only need to get access to the first factor, e.g. the password, which is much easier to implement, and later, when the time of validity of the OTP codes arrives, both factors will be compromised. To address the TOTP code replay attack, the time sync procedure we plan to implement with miniOTP-3 will be combined with reseeding the token. So, a time of a token can only be set together with its secret key.

Meanwhile, worth mentioning that the risk of such attacks is minimal and can be performed only if all the following conditions are met:

• The first factor (username and password) is already known by the attackers
  
• Attackers have physical access to the hardware token
  
• Attackers can discreetly access the hardware token over NFC for a long period of time (i.e. 15–20 minutes are needed to set the time, generate a significant amount of future OTP codes and set the time back).
  

These conditions are relatively hard to be met and can be compared to a situation where a hardware token is stolen. So, we do anticipate that user would want to have a choice between restricted and unrestricted time sync feature, therefore in addition to the programmable tokens with unrestricted time sync feature  we also have programmable tokens with restricted time sync, where setting time will automatically delete the current seed.