1

I am using HOTP to generate OTP to validate a request, in order to prevent replay attacks. I'm thinking about using a window of 10 (or so) iterations to accommodate a possible mismatch in the counter of client and server, but i am a bit concerned about the way i should treat those iterations. Should i reject every token that is less than the last confirmed counter? Or can i have a little margin there?

EDIT:

The reason for me to ask is because i am doing a "three party authentication", by this i mean the device owner authenticates itself by sending a token (with the HOTP in it) and another server will then use it to get something out of a resource server (a bit like oauth but...). So if the device owner authenticates 2 servers the counter will be 1567 and 1568, but if the second server (with the 1568 counter) gets to the resource server first, then the other one will be rejected

Thank you.

0

The "OT" in "HOTP" means "one-time". This is true only if the server indeed rejects passwords corresponding to a counter value which is not greater than the last confirmed value. Having "a little margin" here would mean accepting that a given password is accepted twice, the very thing that HOTP tries to prevent.

This is all based on the idea that the HOTP owner uses his passwords sequentially; there is never a situation where the owner would have any interest in using a password which is not the last one that his password-generating device produced. Correspondingly, if the server received at some point the password corresponding to counter value 1567, then the server knows that the owner's device has gone to value 1568, and any attempt at using, say, password 1565 would be a sure indication of foul play.

The "window" is toward the future, because the device owner may have inadvertently pushed on the button a few times without noticing it, so maybe the next password will correspond to counter value 1575, not 1568, and the server will still accept it.

In other words, the window behaviour as specified in RFC 4226 is the margin you need. There should be no need for any margin in the other direction; if there is such a need, then you are probably misusing HOTP badly.


Edit: if you have several servers consuming one-time passwords from the same source, then I strongly hope that you route all such passwords to a single authentication server, that maintains the counter value. (If this is not the case then you have much bigger issues.)

If you just fear that two such OTP may reach the authentication server "out of order" then you can indeed make things a bit looser without compromising security, but it requires some care. The important property of a one-time-passwords system is that each password value should ever be used once. The counter value, with the semantics explained in RFC 4226, is a cheap and efficient way to maintain these semantics: the server only has to remember the last seen counter, and that's all.

However, you can make the authentication server remember the actually used password values. This can be a "backward window": at any time, the server has a current counter N, which is the highest seen counter value, and remembers all see passwords in the N-9 to N range. With such a window, the server can receive passwords slightly out of order: a password will be accepted if its counter M is greater than N, or is in the N-9 to N range and was not seen yet. The programming on the server is slightly more complex, but not unsurpassingly so.

Important note: the "backward window" is safe in the case of HOTP, but that does not extend to just any "one-time password" scheme. This is safe for HOTP because HOTP is a MAC computed over a counter value -- it relies on the counter not to repeat itself, but not on the possible counter values being used in numerical order. The same would not be true for one-time password schemes which use hash chains (where each OTP is a hash of the next one). What I say here is only for HOTP.

  • First of all thank you for answering. I talked about "a little margin" because being this an indirect authentication that can be issued to more than one server at the same time, i just wanted something that would have some tolerance due slow communications for example... – Snox Apr 15 '14 at 19:12
  • Thank you very much! I'll consider everything you said to carefully design a strategy. – Snox Apr 15 '14 at 20:34

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.