Leaving open, but for now I’ve at least exposed propertties to control the window size and step interval so it doesn’t require any custom work.

The Google library really makes implementing any sort of non-global offset very difficult because it doesn’t tell you what the offset might have been if a token code fails. I suspect it’s just not friendly to address this in a compliant way, and since we’re not really resourced right now to swap in a different library (virtually no usage of this code), I will work on exposing the window size and step size for dynamic resolution.

I don’t think the overhead of tracking the drift per-token is justified vs. simply allowing a larger window to begin with, you end up in exactly the same place, just fewer failed attempts internally.

I haven’t had any time to really consider improvements.

The idea is not to expand the window, but to apply a time offset and to apply the same window on that offset timestamp.

I mentioned the drift problem to our token vendor. This was their feedback:

The issue you describe appears to be related to the configuration of your authentication system. Specifically, it may not be adhering to the TOTP RFC 6238 recommendation, which suggests automatically adjusting for time drift (Section 6 [1]). To address this, the authentication server should be configured to be RFC-compliant. Rather than simply increasing the time window, the TOTP validation mechanism should track and adjust for time drift for each token based on the recorded drift value and direction.

We were already able to expand the window size statically. In the future we will order NFC timesyncable tokens to address this issue.

I’m not really sure how this doesn’t devolve in the end to “pick an upper bound and allow for it”. An attacker would simply game it if the code were to simply allow for a re-validation with an expanding window, whatever the expansion was.

It’s not obvious to me that you can distinguish between the token drifting in one direction, and the use of an old code, which is what an attacker would be generally trying to use.

Other than the overhead of having to try some number of times (pretty bounded, I’d think?), I’m not sure it requires the ability to actually detect that specific issue or the offset. It helps, but not at the cost of using some entirely different and more complex library.

So it seems sufficient to me to expose the setting for the windows size, and just implement a step-wise validation loop that expands up to the limit, and maybe reports the fact that it’s drifting (to allow for a warning of some kind, not sure where/how).

Could also implement the windows size limit myself rather than statically, which would potentially allow it to be derived such that different users or services could get a different limit applied to protect more secure systems.