5

RFC 6238 recommends the server to implement some form of resynchronization algorithm to account for time drift of the device used to generate the OTP. However, the RFC provides very little information on how to actually implement such a synchronization and the consequences it might have on the overall security of the algorithm. This time drift typically is a problem with devices that cannot sync with NTP, such as most programmable TOTP hard tokens. I would like to share our proposal here and hope to come up with an algorithm that is secure, adequately accounts for time drift in devides and requires minimal effort from the end user. I've also added some potential issues I see with the proposal.

Synchronization algorithm

We work with a 30 second window, which is typical for TOTP, but the principal should be the same with other window sizes. In this proposal, n is the current validation window, taking into account the correction for drift as recorded for that device. n-1 is the previous window, n+1 is the next, etc. The delay window (the time between generation of the OTP and its verification) is set at 1 step, as recommended by RFC 6238. This accounts for the difference between searching forward and backward.

  • The OTPs for windows n-2, n-1, n and n+1 are accepted as valid.
  • At n-2 and n+1 the drift for the device is automatically adjusted with -1 and +1 time step respectively.
  • For the other windows between n-6 and n+5, the drift is detected but not automatically adjusted. A manual drift correction is started (described below). The drift detection window of 11 validation windows should be sufficient to allow the user to resynchronize the TOTP when not logging in for a long time.
  • The OTP with a drift correction of 0 is also checked. If this OTP matches, the time drift itself is corrected and a manual drift correction is started to offset 0 (the current server time).
  • All other OTPs are rejected.

The manual drift correction is a process where the user is asked to enter 2 consecutive OTPs. These OTPs are used to calculate the drift within an offset of maximum 1 hour from the system time. Not being able to give 2 consecutive OTPs is considered a failed login attempt.

Possible issues

The RFC recommends against widening the window beyond two time steps (n and n-1). This proposal adds 2 additional time steps (n-2 and n+1) for the automatic adjustment of the offset. I see no way to perform such automatic adjustment without widening the window to at least 4 steps. Of course the automatic adjustment could be left out entirely, but the manual resynchronization is not very pleasant for the end user. Is the widening of the window small enough to maintain a good balance between security and usability?

An OTP will be checked against a total of 13 windows. This could potentially lead to leaking information about the secret. In my opinion this is not a problem, because the recommended length of the secret in combination with the hashing will make it (virtually) impossible to guess the secret, especially when the attempts are rate limited.

Is using 2 consecutive OTPs enough to reliably determine the offset in a window of 240 time steps (1 hour back and forward)? And is a maximum offset of 1 hour good enough to account for time drift of the devices used?

Community
  • 1
Emond Papegaaij
  • 51
  • 2
  • @bk2204 points out that TOTP clients are often mobile apps which synchronize themselves to the internet and therefore clock drift shouldn't really be a problem in practice. Could you clarify the type of TOTP client / device you're using that could result in an hour of drift? Like, are you using TOTP fob tokens? – Mike Ounsworth Jan 06 '21 at 03:36
  • 1
    Colleague of OP here: yes, we are specifically accounting for hardware-based TOTP units that are not (expected to be) synched with external time servers. – Buurman Jan 06 '21 at 07:39
  • 3
    Does this answer your question? [synchronization of keyfob token generator](https://security.stackexchange.com/questions/236684/synchronization-of-keyfob-token-generator) – vidarlo Jan 06 '21 at 09:19
  • 1
    @vidarlo It partially answers the question. The described strategy is still imprecise and lacks an analysis of the impact on security when widening the search window. Also, it does not handle drifts beyond 1 or 2 time steps and does not describe manual resynchronization. As 2FA is at the forefront of our application, we need the strategy to be secure with substantiation on the choices made. – Emond Papegaaij Jan 06 '21 at 09:38

1 Answers1

1

RFC 6238 recommends “that the validator be set with a specific limit to the number of time steps a prover can be "out of synch" before being rejected.” It doesn't recommend a resynchronization algorithm, although it does mention that one could be applied.

In general, the way people usually handle this is to require the TOTP generator to have time synchronization with a reliable source instead of applying a resynchronization algorithm. Because these days most TOTP clients are mobile phones and mobile phones are synchronized to the phone network timestamps by default, this is usually sufficient with a standard ±1 offset.

There are a wide variety of other cases in which having a clock which significantly deviates from standard time is a problem, notably TLS certificate rotation, and users will generally find that not having their device properly synchronized (which, again, even most computers do automatically these days) will cause them serious problems beyond TOTP. Your resynchronization proposal is therefore probably not necessary.

bk2204
  • 7,828
  • 16
  • 15
  • It doesn't actually say it in the question, but I'm guessing they're using like TOTP keychain fobs which have no way to synchronize their time. – Mike Ounsworth Jan 06 '21 at 03:38
  • Colleague of OP here: yes, we are specifically accounting for hardware-based TOTP units that are not (guaranteed to be) synched with external time servers. – Buurman Jan 06 '21 at 07:34
  • You are right @bk2204, the RFC only recommends the specific limit of time steps (as if you can have an unlimited amount of time steps). The section however continues in describing a form of synchronization without giving much details. We are indeed faced with the use of keychain fobs or hardware tokens that can only do TOTP and have no way of syncing the time (other than at the instant of programming the secret). These can drift a lot during their lifespan, much more than a few time steps. – Emond Papegaaij Jan 06 '21 at 17:41