search

go-acme / lego

Let's Encrypt/ACME client and library written in Go
https://go-acme.github.io/lego/
MIT License
7.91k stars 1.01k forks source link

inwx: wait before generating new TOTP TANs #2084

Closed gnoack closed 8 months ago

gnoack commented 8 months ago

This is a workaround for #1608. INWX forbids to re-use the same TOTP twice, but the INWX DNS provider tries to reauthenticate from scratch on each step.

I believe that this is not easily implementable with the existing Lego DNS provider interface, so to avoid refactoring that interaction, let's just make the INWX provider wait a bit until a new token is available. A new token is available every 30 seconds.

The current workaround is to invoke Lego many more times. Retrying at a higher level is worse than retrying here.

Fixes #1608

gnoack commented 8 months ago

This is a good idea, but unfortunately not possible. The period is a system parameter, which the client ("prover") and server ("verifier") must agree on. The TOTP QR code can specify the period, or it will be 30 seconds by default.

More mathematically speaking, the "counter" is derived by dividing the current Unix time in seconds by the period in seconds, rounding down. If we made the period 10 instead of 30, we'd end up with counter values that are three times as high (and generate tokens which are valid roughly at epoch+3*(now-epoch), where epoch is Unix time 0).

So unfortunately, this idea does not work.

(Fun fact on the side, as I've been poking around in the RFC... it seems that by rejecting the second authentication with the same token value, INWX is actually following the RFC recommendation in the last paragraph of RFC 6238, section 5.2.)

gnoack commented 8 months ago

Thank you @ldez for merging this - much appreciated, also for writing the tests, which I missed :)

I had a look at your patches and I think they work. I left some minor comments - I think it is slowing the wait time down a few seconds more than the previous patch did, but I'll happily stand corrected if I am wrong here. But it works anyway, and is an improvement over what this DNS provider did before.