9

I've got multiple OTP managers on my telephone. All of them seem to work with a constant timeout on the one-time passwords that are generated. For instance, the Microsoft authenticator works using a 6-digit time-based (T)OTP that is refreshing every 30 seconds.

The problem is that I often get an OTP that is valid for only a few seconds. The reason for that seems to be that the currently generated OTP is only left valid for that amount of seconds. While waiting some seconds for the next one isn't the end of the world, it does annoy me from a user-experience perspective. Often I find myself entering the code in the last few seconds, only for the code to timeout before I can hit enter.

Are there any OTP standards that somehow avoid this issue? If so, are there any authenticators that do always have a password ready for a reasonable amount of time, so that the number can always be copied before the timeout?

[EDIT] In hindsight the OTP is only shown for a couple of seconds, but the code may still be valid on the server some amount of time after that. However, this will leave the user very little time to copy the code - and that's probably the factor that takes most of the time.

Improve this question
4
  • 2
    It seems that this issue is likely one of the following: 1) the TOTP generator is generating TOTP codes based on a time in the past, or 2) the server is invalidating TOTP codes too quickly. To isolate the problem to one of the above, you might want to consider using this TOTP generator in python and modifying it so that it shows not only the TOTP code, but also the time that the TOTP code is based on as well.
    – mti2935
    CommentedApr 23 at 17:21
  • 2
    @mti2935: From what I understand now, the OP actually describes a GUI issue where the authenticator app doesn't always start the counter at 30 seconds but may display the code only for a few seconds -- even when applications typically have a grace period where expired codes are still accepted for some time. If this is indeed the problem, the only solution is to find a more user-friendly authenticator app (or write one yourself).
    – Ja1024
    CommentedApr 23 at 18:04
  • Yeah, that seems to be the case. Adjusted the question with a clearly marked EDIT, didn't know that the code would still be valid even after it seemed to timeout in the OTP app.
    – Maarten Bodewes
    CommentedApr 23 at 21:32
  • 2
    The "Ente Auth" app displays the current code and the next code. So if it's about to switch over you can start typing in the next code and submit it once it becomes the current code.
    – Yay295
    CommentedApr 25 at 5:15

3 Answers 3

Reset to default
10

It's certainly annoying when you open the authenticator app and only see the current code for a short time before a new code is generated, but this is a correct implementation of the current TOTP specification.

The time steps (usually 30-second intervals) are counted from an absolute starting time T0 (the Unix epoch by default), so it's possible that the current step is almost over when you open the app. In the worst case, the remaining time is too short to use the shown code but so long that it takes a while for the next code to be displayed.

In practice, many applications using TOTP for authentication allow codes from past and/or future steps. This is done to account for time synchonization issues between the authenticator device and the target application. So a code which is displayed for 30 seconds may actually be valid much longer. The developers of authenticator apps could assume that almost all applications have this grace period. Then it's reasonable to display the current code for a longer time, e.g., always 30 seconds regardless of when the current step started. However, if the target application doesn't have a grace period, then the code you see on the screen may have already expired, and entering it would be a waste of time.

So there's currently no real solution. If you're pretty sure that most of the target applications accept expired codes, then you could look for (or implement) an authenticator app which displays the code longer than the actual time step interval. I believe the Google authenticator did this at some point, but it's apparently no longer the case. In the future, maybe the otpauth URL format will be updated to include a parameter which tells the authenticator app how many backward and forward steps are acceptable. Then the app could decide to display a code even after the current step.

Improve this answer
4
  • 1
    @MaartenBodewes: Then use a different authenticator app. For example, the Google authenticator always starts the countdown at 30 seconds, even if technically some time has already elapsed since the last code.
    – Ja1024
    CommentedApr 23 at 16:14
  • I thought it did that as well, but even after killing the app and restarting some time seems to have passed before I can see the values. Tried the 3 apps (Microsoft, Google & a free OTP app) before I posted. I'll have another look.
    – Maarten Bodewes
    CommentedApr 23 at 16:22
  • @MaartenBodewes does this happen with various servers, or just a specific one? Maybe the server time is off.
    – Paŭlo Ebermann
    CommentedApr 24 at 0:42
  • @PaŭloEbermann I think there is some confusion here. I assume that the "Google Authenticator" is the app. So the server is not yet in view.
    – Maarten Bodewes
    CommentedApr 24 at 10:58
23

The TOTP standard considers this.

It RECCOMENDs to allow for 1 timestep of delay (30 seconds)

It states that a verifier "SHOULD typically set a policy for an acceptable OTP transmission delay window" So even codes that look to have expired on your client may be valid to the server.

In regards to avoiding the issue, the HOTP algorithm (essentially TOTP but with a counter not a timestamp) solves this specific issue but introduces others, such as desynchronisation.

Improve this answer
2
  • 17
    Adding to this, of the more than 50 TOTP systems I’ve dealt with, I have only ever seen one that did not have a grace period like this. Not all of them go for the full timestamp duration of delay, but most will allow at least half a timestamp of delay.
    – Austin Hemmelgarn
    CommentedApr 23 at 20:22
  • 1
    I would be surprised to see an implementation that did this based upon the actual time, rather than discrete timesteps. It's much easier for the implementation to take the current time and determine which code(s) are currently valid. That may be the truly-currently-valid code, the most-recently-valid code and the next-valid-code in the future. Or you could do the current one and two in the past. Or only one in the past. It's more difficult to say "this code is valid, but only for another timestep/2 seconds" and easier to say "only these codes are valid."
    – Christopher Schultz
    CommentedApr 24 at 22:32
0

Are there any OTP standards that somehow avoid this issue? If so, are there any authenticators that do always have a password ready for a reasonable amount of time, so that the number can always be copied before the timeout?

The core idea behind an One Time Password is that an algorithm generates a short, ephemeral password as a way to provide a second factor. In this case, the factor is something you have, i.e. the secret code that can be used to seed this algorithm. the generated value is derived from that seed value and the current time.

Because a value that is based on the exact time would provide rapidly changing OTP codes, an agreement has been made that this time is rounded to the nearest 30 seconds. This means that all OTP codes generated using the same algorithm will refresh at the same time. This also means that sometimes you may want to use a OTP code at a slightly inconvenient time, such as right before a refresh moment.

There is not really a way to work around this, at least not with TOTP algorithm generated codes like those generally used with authenticator apps. Other algorithms might provide alternative generation techniques, but those have other risks involved that could lead to your code not being accepted.

Improve this answer
3
  • I'm wondering if a "pause" button would not work given that the server is probably accepting slightly older OTP anyway. Yeah, I see the synchronized updates of the code (probably sequentially generated, but you would not be able to see that on a modern smart phone).
    – Maarten Bodewes
    CommentedApr 24 at 11:22
  • 1
    @MaartenBodewes A simpler UI implementation would be when the current code expires, continue to show it, e.g. in grey, smaller font and underneath the current code, so that you can continue entering it.
    – user71659
    CommentedApr 24 at 19:50
  • @user71659 Yeah, I thought about that, but a pause button that keeps showing the current number seems more logical. You can be sure that people will get confused if you show two numbers and then switch them around etc. Of course the pausing should stop when it is unlikely that the server will accept the code.
    – Maarten Bodewes
    CommentedApr 24 at 21:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.