On git master, and for 1.10.0, I have added new APIs to return the position in the search window for a TOTP. The otp_pos output value works as follows:
140852 otp_pos=-2 299833 otp_pos=-1 044488 <= time now, otp_pos=0 584072 otp_pos=1 000706 otp_pos=2 The usersfile code will compute the OTP position in the window for both the current OTP (under verification) and the last accepted OTP, thus we can have: 140852 299833 <= last OTP according to usersfile 044488 <= time now 584072 <= new OTP under validation 000706 512368 It will notice that 3 > 1 and permit the authentication. Whereas in a later situation, we could have this: 140852 299833 044488 <= new OTP under validation 584072 <= last OTP according to usersfile 000706 <= time now 512368 The code will notice that 2 < 3 and reject the authentication. The search window size will need to be the same during subsequent validations, otherwise we may end up in a corner case. Consider run 1 with a search window of 4: 044488 584072 000706 512368 094088 <= time now 755942 936706 369736 <= OTP received 787399 The OTP will be accepted (otp_pos=3), and 369736 will be recorded as the last OTP. Let's say some code is running a new validation with search window of 2 just milliseconds later, then we'll have: 044488 584072 000706 512368 094088 <= time now 755942 936706 <= OTP received 369736 <= last OTP 787399 Searching for 369736 will fail (not within search window of 2), and the code assumes that OTP is older than the entire search window, and it will incorrectly permit 936706 as an OK incoming OTP. By always using the same search window size for each user, this problem is avoided. I think it is normal to use the same search window, so I don't think it is a problem. What do you think? /Simon
