Well, considering I was part of the implementation team of one of those hardware tokens, I'm sorry I'm going to have to disagree with you :). Please note that I

Well, considering I was part of the implementation team of one of those hardware tokens, I'm sorry I'm going to have to disagree with you :). Please note that I'm not talking about RFC6238 / 4226. I'm talking about proprietary implementations for hardware tokens. We most definitely had drift management. One of the differentiating features to our competitors is that our algorithm had both a "click counter" (number of times the button was pressed) and a "clock counter". The least significant digit of both counters was included in the OTP that was generated. The authentication server used the last digit of both counters to figure out what values to use, and as you say, generated codes in both time directions in order to try and identify the values of the counters (well, the click counter obviously didn't go both directions). The server then stored the last matching click counter value and the drift of the clock value. It wasn't uncommon to have tokens that drifted by multiple minutes per month. This being said, you're right: the clock only incremented every 28 or 32 seconds, not 2.5 seconds as I incorrectly remembered.