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.
DUO: “TOTP tokens that drift out of synchronization cannot be resynced with Duo”
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).
“even 1-second drift per day is not something unusual for a TOTP hardware token”
After a period of time (i.e. 1–2 years) many of the tokens will drift outside of 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.
Token2 miniOTP-2 — the first ever programmable hardware token with time synchronization
To address the issue above, TOKEN2 R&D team is working on a solution that would allow syncing the clock of hardware tokens using a special app, so this article is an early announcement of a new product, tentatively planned to be named miniOTP-2. We are already selling programmable tokens (miniOTP-1) where users can set seeds using our burner app via NFC. However, there was no way to fix the time drift on hardware tokens, even programmable ones.
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-2 will be combined with reseeding the token. So, a time of a token can only be set together with its secret key. The fact that the seed can only be set and never read from our programmable tokens ( the current model and the future miniOTP-2) will make sure the seed is only accessible by the authentication server. Therefore, unauthorized access to the time adjustment of the hardware tokens will not result in the replay attack. Contrary to this, if the time setting is set by a legitimate user (i.e. the administrator), the seed set together with the correct time value will also be set at the authentication server, or vice-versa, a new seed will be requested to be generated by the authentication server to be written to the token together with time synchronization.
Meanwhile, worth mentioning that the risk of such attacks is minimal and can be performed only if all of 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.
As per our research, currently, there are no TOTP hardware tokens with time synchronization feature existing on the market, meanwhile, this feature is in very high demand as per the feedback we are getting from our customers. Being big fans of TOTP as a protocol, we believe it will get its second breath with our new product — miniOTP-2 a programmable hardware token with time synchronization. Furthermore, this will be a huge step towards investment protection for organizations willing to invest in TOTP hardware tokens: miniOTP-2 can be used (and reused) until squeezing the very last drop out of token’s battery!
Token2 miniOTP-2 is currently being pilot tested and prepared for mass production, sales are expected to commence in Q2 2019.
About Token2
TOKEN2 Multifactor authentication products and services LTD (short name TOKEN2) is a multinational IT security company headquartered in Versoix, Switzerland, providing various security solutions, such as hardware tokens, a mobile application, TOTPRadius server (an on-premises Radius server designed for two-factor authentication) and Token2 Cloud API, a hosted two-factor authentication service designed to protect primarily Web-based applications.
