1
$\begingroup$

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?

| improve this question | |
$\endgroup$
  • $\begingroup$ sending the counter gives an attacker a lot more information $\endgroup$ – Richie Frame Mar 13 '14 at 19:20
  • $\begingroup$ @RichieFrame Shouldn't matter. $\endgroup$ – CodesInChaos Mar 13 '14 at 19:48
  • $\begingroup$ probably not in practice, the most logical real reason it is not sent is because the counter is 64-bits, and it is easier for people not to type the extra 11+ characters $\endgroup$ – Richie Frame Mar 13 '14 at 19:59
  • $\begingroup$ @RichieFrame It should not matter, in totp schemes the counter is based off time, which is public knowledge. On the second point the reason I suggested a Yubikey is that the burden of entering the count, in addition to the otp, is offset by the device entering the value for the user(the reason why Yubikey's use 160bit otp's rather than the defacto 6 digit otp). As you point out the requirement to enter the count and then the otp is to taxing on the end user and would lead to some abandoning using second factor altogether. $\endgroup$ – Joseph L. Mar 14 '14 at 21:32
  • $\begingroup$ The only way I can see this changing is if devices start using NFC or properly implemented Bluetooth to input the codes. but I don't see that coming to light anytime soon. Apple has outright refused to support NFC. Even now, companies are slow to take up 2fa, and there isn't even an established standard for 2fa. $\endgroup$ – Joseph L. Mar 14 '14 at 21:43
0
$\begingroup$

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.

| improve this answer | |
$\endgroup$
0
$\begingroup$

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

| improve this answer | |
$\endgroup$

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.