2

I was trying to figure out how HOTP kept from wrapping over, when I saw this explanation of how it works, by Thomas Pornin [source]:

The intended scenario is the following: the client has a handheld device which outputs the successive passwords, one new password per button-press. The client may press the button a few times between two login attempts. The server "bets" that the client will not press the button more than, say, 100 times before attempting to log in again: so the server uses $w \leq100$. If you let your 3-year-old nephew play with your HOTP device a whole afternoon, chances are that it will be too much desynchronized, and login will not work any longer.

Assuming the user didn't have to input the OTP value or counter number(lets assume its something akin to a yubikey), what would be the downside of having the device feed the site with what the counter number is on, before giving the resulting OTP to check against?

Community
  • 1
Joseph L.
  • 23
  • 3

2 Answers2

0

Your question starts from an assumption that often isn't valid. You write:

Assuming the user didn't have to input the OTP value or counter number

but in fact, for cost reasons, often these devices don't haven't any way to send the counter number to the server; the user would have to input it.

If the counter value is actually based upon the time, so it doesn't need to be sent, then yes, the quote from Thomas Pornin doesn't apply. For those kinds of tokens, yes, the server can use the time and we don't have the issue with it getting desynchronized if you press the button 100 times. The server does still need to make sure that the token's time approximately matches the server's time, and that the number only increases (to avoid replay attacks).

D.W.
  • 36,982
  • 13
  • 107
  • 196
0

If you assume a device, which can directly communicate with the server, then there is no real downside if it's implemented correctly:

  • The token states the counter, which is just a predictable nonce (no need to keep it secret).
  • And then it gives out the OTP based on the nonce and the key.

To avoid replay attacks, the server has to check that the counter has increased since the last login, but then it should be fine.

However, if this direct communication channel between server and token is not unidirectional, then you don't need a OTP but you can just run a standard challenge-response authentication protocol. The only thing that changes is that the server chooses the challenge instead of using a counter.

Btw, in order to avoid MitM, it's useful to have mutual authentication, not just one way.

tylo
  • 12,864
  • 26
  • 40