TOTP check should tolerate clock drift
Concerned version
Version: 2.0.9
Summary
The "Range of attemps" TOTP parameter lets the server check TOTP codes against codes generated more than 30 seconds ago.
It helps if the user's clock is a little behind the server's clock, too. This is permitted, and even recommended by RFC6238:
Because of possible clock drifts between a client and a validation
server, we RECOMMEND that the validator be set with a specific limit
to the number of time steps a prover can be "out of synch" before
being rejected.
This limit can be set both forward and backward from the calculated
time step on receipt of the OTP value. LLNG currently checks backward, but not forward. So if the server's clock is behind the user's clock, verification will fail.
Possible fixes
totp2fRange should be modified to also check in the future.
instead of checking [0, rangeinterval] we should check [-rangeinterval, +range*interval]
We should make a release note to warn our most security conscious users about this, just in case