5 ms·

TOTP issues related to bogus clocks are soooooo common that I've got my own public TOTP "secret" (so not really a secret) which I use to verify that my various

TOTP issues related to bogus clocks are soooooo common that I've got my own public TOTP "secret" (so not really a secret) which I use to verify that my various devices running TOTP authenticators have the correct time (my phone, wife's phone, an airline/airgapped device running TOTP etc.). It's so bad that Google's own authenticator has a "time synch" functionality or something like that in the very TOTP app (and it helps!). This speaks volume as to how bad and how not-solved-at-all the issue of drifting/wrong clocks is. I much prefer U2F.

orev 5y ago
TOTP systems are supposed to implement a sliding window to account for reasonable clock differences, usually within 5 minutes. Devices further off from that really do have a problem, and should not be trusted. I also find it hard to believe that so many devices are so far off, given the ubiquitous access to GPS (atomic clock) signals and NTP on networks. This has been a solved problem for a long time.
- nfoz 5y ago
  > TOTP systems are supposed to implement a sliding window to account for reasonable clock differences, usually within 5 minutes. The default is 30 seconds, as per the RFC: https://datatracker.ietf.org/doc/html/rfc6238 https://datatracker.ietf.org/doc/html/rfc6238 (not sure that meaningfully changes what you were saying, but just fyi.)
  - orev 5y ago
    30 seconds is the default “time step” (4.2), but in talking about the transmission delay window (5.2), which the RFC recommends “at most 1 time step”, but also says that validation should occur for both the previous and next time step window. However in practical implementations, 5 minutes on both sides is typically used.
- Avamander 5y ago
  As long as an Android or OSX phone has internet access and it isn't totally messed up, it'll pull time from NTP if the modem's time doesn't exist. I too have doubts that many devices are so far off.

orev 5y ago

TOTP systems are supposed to implement a sliding window to account for reasonable clock differences, usually within 5 minutes. Devices further off from that really do have a problem, and should not be trusted. I also find it hard to believe that so many devices are so far off, given the ubiquitous access to GPS (atomic clock) signals and NTP on networks. This has been a solved problem for a long time.

nfoz 5y ago
> TOTP systems are supposed to implement a sliding window to account for reasonable clock differences, usually within 5 minutes. The default is 30 seconds, as per the RFC: https://datatracker.ietf.org/doc/html/rfc6238 https://datatracker.ietf.org/doc/html/rfc6238 (not sure that meaningfully changes what you were saying, but just fyi.)
- orev 5y ago
  30 seconds is the default “time step” (4.2), but in talking about the transmission delay window (5.2), which the RFC recommends “at most 1 time step”, but also says that validation should occur for both the previous and next time step window. However in practical implementations, 5 minutes on both sides is typically used.
Avamander 5y ago
As long as an Android or OSX phone has internet access and it isn't totally messed up, it'll pull time from NTP if the modem's time doesn't exist. I too have doubts that many devices are so far off.