[OATH-Toolkit-help] logic for TOTP validation

[Simon Josefsson]

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