7

I often see two-factor authentication (2FA) methods using one-time passwords (OTP) implementations wherein the current (previous) and sometimes even 2 or 3 previous tokens are still valid. This is probably done for several reasons, I can think of:

  • to overcome possible time sync issues between the client and server (user experience),
  • for convenience of the sysadmins not to constantly have support calls about not being able to login.

Is accepting the previous OTP a bad practice? And if so, what is the general recommendation regarding the implementation of such "features"?

Correct me if I'm wrong but when the token is 6 digits, the number of possible combinations are 1.000.000 (000000 - 999999). So only 1 in a million tokens in accepted during a 30 second time-span. But when accepting the previous (or even more previous) tokens the chances are basically 2, 3, 4, or 5 in one million.

Jedi
  • 3,906
  • 2
  • 24
  • 42
Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
  • Are you asking about 2 Factor Authentication (2FA) or One Time Passwords (OTP)? – Stevoisiak Jun 22 '17 at 18:16
  • 2
    @StevenVascellaro Clarify what you mean by "or"? What 2FA that generates a code for the user isn't an OTP? One is an implementation of the other. – Nalaurien Jun 22 '17 at 18:33

2 Answers2

9

If by previous you mean an OTP that predates one the user already authenticated with then yes, this is considered bad practice. The OTP is meant to be used once, hence the name. The whole point of 2FA is that it represents the "something you have" in the security trinity. Allowing a token to be used twice defeats the purpose of what OTPs are meant to prevent. Turning it into "something you know" which makes it just a second password.

This problem usually doesn't present itself as a brute force issue. For example in the case of TOTP where the time windows are relatively short, brute forcing isn't really used to circumvent it. The use case as an attacker for a site that allows OTPs to be reused, either current or past is interception.

If the client uses the OTP and it is somehow intercepted, the attacker now reduces the problem to username password. Which, if they're intercepting information is likely also listening for these.

In the case of HOTP the problem is even worse, because theoretically the counter or moving factor does not increment very often. Meaning the last or even previous OTP the user authenticated with will likely be valid for a long time. In some cases months depending on the implementation of the server.

If by previous you mean the OTP on or before the current one being generated but not yet used, then no, within limits. Standard implementations of OTPs apply a "window" to overcome sync issues usually. In the case of TOTP, a 5 second window is employed (both forwards and backward) but this, in any implementations that I have seen, always disallows any OTP that is on or before the last one the user authenticated with. If we take the case of a 15s moving step with a 15s window there would be three OTPs that can be used to authenticate over a 45s timeframe, one in the past, one now and one in the future (this assumes the interval is the same as the moving step). The reasoning behind this is elegantly explained in @cornelinux's answer.

For HOTP the window is a "look ahead" window. The last OTP the user authenticated with was allowed if it was within the next 10 OTPs of the previous one accepted, and then the implementation calculates the next 10 from that one for the check against the next OTP entered. It has the considerable good sense to disregard any of the OTPs not used in the window before the one used successfully.

Note:

In HOTP 10 is arbitrary. Usually the factor is about 2.5 times the number of OTPs required to authenticate successfully. So if the user needs 3 HOTPs to authenticate the window will be about 8 OTPs after the current one.

In TOTP 5 seconds is also variable. In some cases I've seen windows as large as 100% of the moving step. So with a 30s step and a window of 30s effectively makes a code valid for 1:30. Again, expanding both before and after the current iteration.

Nalaurien
  • 1,614
  • 9
  • 16
  • 2
    I like this answer – ISMSDEV Jun 22 '17 at 12:46
  • 1
    This is not what OP was asking. OP was asking if accepting the previous 2 or 3 tokens of a TOTP generated x seconds and x * 2 seconds prior to the current one is dangerous. Not about tokens that have been used successfully before. – Hatted Rooster Jun 22 '17 at 16:03
  • 1
    @GillBates Actually OP does not specify this. Which is why I included it in the answer. You can view it as section 1 and section 2. Section 1 dealing with the case where "previous" means the OTP is on or before the last one authenticated. Section 2 where "previous" can apply to the window before or after the current iteration (i.e. not yet authenticated). – Nalaurien Jun 22 '17 at 16:06
5

You may also want to take a look at RFC6238 (TOTP). https://www.rfc-editor.org/rfc/rfc6238#page-6

There is a timewindow for verifying the OTP value. (As @Nalaurien pointed out, only once). Allowing an older or even newer TOTP value has also practical reasons: clock skew of a hardware token and the time the user needs to read and enter the OTP value.

Clock Skew and Hardware

Note that TOTP was specified in 2011. HOTP, which is the basis for TOTP, was even specified in 2005. The iphone 1 was released in 2007. TOTP was never ment to run on a smartphone but on cheap hardware key fobs with a bad clock with a probably drifting time.

You may also notice that HOTP (RFC4226) and TOTP (RFC623) where written by people working at authentication hardware companies and not with Google or Apple. ;-)

Community
  • 1
cornelinux
  • 1,993
  • 8
  • 11
  • What hardware companies developed it? – Bob Ortiz Jun 22 '17 at 17:19
  • "(As @Nalaurien pointed out, only once)" Thank you for pointing this out, I will expand that part of my explanation a bit. – Nalaurien Jun 22 '17 at 19:38
  • @KevinMorssink Vasco, Gemplus, Aladdin, Portwise... The openauthentication initiative has software and hardware vendors. But most of the founding fathers are also hardware vendors (since the were no soft-token or virtual tokens at this time) – cornelinux Jun 22 '17 at 21:27
  • @cornelinux Interesting background information. Thank you. – Bob Ortiz Jun 22 '17 at 23:45