Comment by jqpabc123
4 days ago
I implemented TOTP as a command line app doing lookup and generation by pulling secrets from a locally encrypted password file.
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.
In my experience HOTP works fine, why not. The real world deployment is a replacement for sms otp.
Client and server can potentially agree on the counter with a handshake.
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.
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.
2 replies →