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).

schroeder
  • 123,438
  • 55
  • 284
  • 319
U. Windl
  • 137
  • 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 05 '21 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 05 '21 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 05 '21 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 05 '21 at 14:23
  • @default But "blocking" would be more "man-in-the-middle" than "replay attack", right? – U. Windl Nov 08 '21 at 08:32
  • @schroeder I don't see the semantic difference between "end-to-end encryption" and secure channel. The emphasis of the question is not "*should*" vs. "*requires*", but whether a replay attack is possible if there is no "secure channel". – U. Windl Nov 08 '21 at 08:34
  • Encryption is just one way to secure a channel. "End-to-end encryption" is a very specific form of encryption. So, yes, there is a massive difference technically as well as semantically. And, yes, I edited your question to be about the lack, not the necessity. – schroeder Nov 08 '21 at 09:17

1 Answers1

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.

bk2204
  • 7,828
  • 16
  • 15
  • 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 07 '21 at 14:29
  • However *5.2. Validation and Time-Step Size* of (RFC 6238)[https://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 08 '21 at 08:43