And before someone asks, the decrypt key is only stored in my head and the app fails silently after a significant delay if the decrypt fails.
What I don't get is how HOTP is anything but a fail waiting to happen if used across an unreliable network. Maybe this explains why I have yet to encounter a real world deployment of HOTP.
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.
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.
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.