[jqpabc123]

How does such a handshake agreement get triggered?

How does the server know that the handshake request is not malicious? 2FA that is resettable on demand (without 2FA) effectively voids the whole concept does it not?

With HOTP, the counter is the shared secret --- but a dynamic and potentially unstable one. One failed request or one missed response and the counters on client and server are no longer in sync. Hence, a failure waiting to happen on an unreliable network.

[dogacel]

Why counter is the shared secret? In TOTP time is the counter and it is obviously not secret, so there is no reason to think the counter would be secret as well. Clients can sync their counter to match the server.

[jqpabc123]

In TOTP, time exists independent of both client and server and as you point out, is no secret to either.

In HOTP, the secret counter is not independent and must remain synchronized between client and server.

A counter that can be synchronized on demand is kinda superfluous --- not really secret and not terribly relevant either. All else being equal, an attacker can sync up just as easily as a legitimate client so why bother with the counter?

I expect HOTP exists somewhere out there in the real world but I have yet to encounter it. Every 2FA I have actual experience with has been TOTP.

[dogacel]

> A counter that can be synchronized on demand is kinda superfluous --- not really secret and not terribly relevant either. All else being equal, an attacker can sync up just as easily as a legitimate client so why bother with the counter?

A unique counter for each authorization attempt ensures the resulting key is different for each attempt, which makes replay attacks not possible. I agree if you sync the counter two ways, it is better to use a "nonce", a totally random secret each time.