The previous implementation required entering a number of consecutive
OTPs followed by another OTP value anywhere in the autoresync range. In
particular it was allowed to just repeat the previous OTP. That is for
two required consecutive OTPs, it would be possible to resync by
entering "a", "b", "b". Thus the requirement to enter the last OTP of
this sequence does not improve security but reduces user friendliness.

The new, simplified implementation, just resyncs automatically once the
required number of consecutive OTPs is reached. A successful resync also
counts as a successful authentication. Thus it is sufficient to just
enter "a", "b".

From a security perspective the requirement for consecutive OTPs should
(virtually) rule out any chance for an attack. An attacker would have to
guess all numbers of the two OTPs combined, which essentially doubles
the OTP length. It is much more likely guess an OTP value within the
standard lookahead range than to guess two consecutive OTPs correctly.

A similar mechanism for counter resynchronization is also used for
example by FreeIPA: https://www.freeipa.org/page/V4/OTP#Token_Synchronization_2

arw authored 5 years ago and Thomas Preisner committed 3 years ago

When a hardware/software token has drifted too far into the future, autoresync
advances the counter to resync. This only happens if a sufficient number of
good tries happened in sequence. Each of those good tries will be denied, the
next one however will resync the counter.

make the linter STFU

See merge request !1

Got severely fucked up in commit
58d65e2e, so that is suddenly expects a
different config format, restore the old one.

test against the standard versions in stretch and buster as well as the
latest go release on each of them.

should be valid for long enough now hopefully

`make test` is currently failing when building with  sbuild because it tries to run the
postgres database as root, which is not allowed. Since the test cases are also run using the
Gitlab CI, we ignore this issue for now.

If len is zero the while loop is skipped and sent is never initialized.

All callers pass len > 0 so this issue doesn't occur in practice yet.

Scan() can return true despite encountering an error. Encountered while
writing a test for the read timeout, also included.