TOTP check should tolerate clock drift
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.
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