1

RFC 4226 on HOTP (7.1 Authentication Protocol Requirements) says

RP3 - P [the protocol] SHOULD be implemented over a secure channel in order to
protect users' privacy and avoid replay attacks.

But isn't the basic idea of HOTP (and TOTP) not to require to make the response secret (The "OT" in OTP) once being used? The same response cannot be used twice to authenticate.

IMHO end-to-end encryption is necessary to prevent man-in-the-middle (MITM) attacks where the security response does not authenticate the user, but the attacker (using the correct but redirected response from the user).

7
  • You said that it was necessary. The RFC says "should". You also said that it required end-to-end encryption. It doesn't. In fact, the term "end-to-end" isn't mentioned anywhere in the RFC. So, since you misunderstood the RFC and your understanding has now been corrected, do you still have a question?
    – schroeder
    Nov 5 at 13:19
  • No, HOTP's idea is not to "make the response secret". You simply invalidate the code once used. There's nothing "secret" about that.
    – schroeder
    Nov 5 at 13:25
  • 2
    Replay attack doesn't work on One Time Tokens. You still need a secure channel to enter HOTP because the attacker can block your request and use your HOTP.
    – defalt
    Nov 5 at 13:53
  • @defalt it could work if the code is not invalidated. This can happen with TOTP, especially. So the channel should be secure in case the invalidation process fails or is weak. HOTP is strange because I can't imagine a way for a replay to work, unless it is intercepted from the client.
    – schroeder
    Nov 5 at 14:23
  • @default But "blocking" would be more "man-in-the-middle" than "replay attack", right?
    – U. Windl
    Nov 8 at 8:32
2

In a traditional HOTP setup, the counter version is stored by the server, and only a small number of codes are accepted (those for the next N counters). This typically prevents replay attacks, since the server will typically not accept earlier codes. There may, however, be a small time window in which a code remains valid depending on the implementation of the server (due to things like database lag or such).

However, TOTP is essentially HOTP where the counter value is a timestamp. In this scenario, you can indeed replay values over a short period. For example, if you log into an unencrypted website on a coffee shop Wi-Fi, then anyone else on the network can snoop it and log in with your credentials shortly after you, and then your account is compromised. Using a secure channel, such as TLS or SSH, prevents this problem because TLS and SSH contain their own defenses against replay attacks and the TOTP value isn't visible to the attacker.

So while this is less likely with standard HOTP, since TOTP is essentially HOTP and it does suffer from this problem, this is a thing that you do need to handle in practice. Of course, you should have been using a secure channel anyway, because that's considered the minimal level of acceptable security for untrusted networks these days.

2
  • I've edited it to include text about how secure channels do indeed prevent replay attacks because the TOTP value is not known and the channels contain replay defenses.
    – bk2204
    Nov 7 at 14:29
  • However 5.2. Validation and Time-Step Size of (RFC 6238)[datatracker.ietf.org/doc/html/rfc6238#page-6] says in the last paragraph: "The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP."
    – U. Windl
    Nov 8 at 8:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.