7 ms·

You know in Authy (Google Authenticator is similar here?) when there's only 10 seconds or so left to type in the current code so you wait for the next one to ap

You know in Authy (Google Authenticator is similar here?) when there's only 10 seconds or so left to type in the current code so you wait for the next one to appear? Could it not show the next code instead if there wasn't much time left and the app you're authenticating with could accept the current or next code? Feels like an obvious annoyance that's fixable.

anchpop 5y ago
I’ve thought about that too. It should always show two codes (the current one and the previous one), and websites should accept both. Then when you open the app, you can always start typing the most recent one and have at least the whole interval to type it in
pgalvin 5y ago
This is mostly a non-issue - services usually accept the current, previous and next TOTP code to account for devices having a slightly incorrect clock. I’ve never had an Android device that keeps its clock in sync, for example, so they had to address this.
b3morales 5y ago
The server sides are typically set up with some flexibility to account for the latency and avoid this UX issue. They will have a window to accept the previous/next code even after the new becomes active. To avoid replays, though, this should be reset once a code is accepted: only subsequent codes should be accepted afterwards. So when code N is the "correct" code, any of N-1, N, or N+1 will be accepted. But if N is entered, only N+1 and onwards should be accepted for later attempts.
kccqzy 5y ago
Servers generally have no problem accepting an expired code, if the code is only expired for a few seconds.
deleted 5y ago
[deleted]
pmlamotte 5y ago
Showing two codes would definitely be a nice opt-in feature. Servers generally will compute codes within a sliding window to account for time sync discrepancies so there wouldn't be much harm. I could see how it may be confusing to some end users though.
ecesena 5y ago
Codes are typically valid for 3-5min even if the display only shows 1min. This is to avoid issues with time discrepancy on client/server, and doesn't really make a big difference in terms of security, feel free to try it out. So, to fix your issue, just use the current code even if it seems expired. As a side note, it's important to enforce that each code can only be used once. Authy (the server-side service) does that, but many "roll your own" TOTP solutions don't verify this.
- JyB 5y ago
  Not sure how that's relevant to the parent.
  - ecesena 5y ago
    > Could it not show the next code [...] ? Codes are typically valid for 3-5min [...] just use the current code even if it seems expired
tialaramex 5y ago
A good implementation of this protocol remembers that it saw this code and won't let anybody re-use it. For example suppose I am standing behind Sarah as she logs in to her bank and I happen to already know that her "Favourite carebear" was "Birthday Bear" even though that's not displayed on screen, and I see she types 123 456 as the TOTP code. If I am very quick and try to also log in to her bank with "Birthday Bear" and 123 456 that shouldn't work even though that's still the "right" code for the next few seconds. The bank login should tell me that I need to wait and enter the next code. I can't see Sarah's next code because she's done and put her phone away. RFC 6238 says of this: "The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP."
JyB 5y ago
Try it. They'll still work if the server side is implemented properly. The server will be lenient on the timestamps.
graftak 5y ago
Raivo OTP for iOS does something similar where it displays the previous code (greyed out) too after it has expired. Convenient for when the time runs out while you enter the code, as others mentions there is often some leeway on the token expiry time.

anchpop 5y ago

I’ve thought about that too. It should always show two codes (the current one and the previous one), and websites should accept both. Then when you open the app, you can always start typing the most recent one and have at least the whole interval to type it in

pgalvin 5y ago

This is mostly a non-issue - services usually accept the current, previous and next TOTP code to account for devices having a slightly incorrect clock. I’ve never had an Android device that keeps its clock in sync, for example, so they had to address this.

b3morales 5y ago

The server sides are typically set up with some flexibility to account for the latency and avoid this UX issue. They will have a window to accept the previous/next code even after the new becomes active. To avoid replays, though, this should be reset once a code is accepted: only subsequent codes should be accepted afterwards. So when code N is the "correct" code, any of N-1, N, or N+1 will be accepted. But if N is entered, only N+1 and onwards should be accepted for later attempts.

kccqzy 5y ago

Servers generally have no problem accepting an expired code, if the code is only expired for a few seconds.

deleted 5y ago

[deleted]

pmlamotte 5y ago

Showing two codes would definitely be a nice opt-in feature. Servers generally will compute codes within a sliding window to account for time sync discrepancies so there wouldn't be much harm. I could see how it may be confusing to some end users though.

ecesena 5y ago

Codes are typically valid for 3-5min even if the display only shows 1min. This is to avoid issues with time discrepancy on client/server, and doesn't really make a big difference in terms of security, feel free to try it out. So, to fix your issue, just use the current code even if it seems expired. As a side note, it's important to enforce that each code can only be used once. Authy (the server-side service) does that, but many "roll your own" TOTP solutions don't verify this.

JyB 5y ago
Not sure how that's relevant to the parent.
- ecesena 5y ago
  > Could it not show the next code [...] ? Codes are typically valid for 3-5min [...] just use the current code even if it seems expired

tialaramex 5y ago

A good implementation of this protocol remembers that it saw this code and won't let anybody re-use it. For example suppose I am standing behind Sarah as she logs in to her bank and I happen to already know that her "Favourite carebear" was "Birthday Bear" even though that's not displayed on screen, and I see she types 123 456 as the TOTP code. If I am very quick and try to also log in to her bank with "Birthday Bear" and 123 456 that shouldn't work even though that's still the "right" code for the next few seconds. The bank login should tell me that I need to wait and enter the next code. I can't see Sarah's next code because she's done and put her phone away. RFC 6238 says of this: "The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP."

JyB 5y ago

Try it. They'll still work if the server side is implemented properly. The server will be lenient on the timestamps.

graftak 5y ago

Raivo OTP for iOS does something similar where it displays the previous code (greyed out) too after it has expired. Convenient for when the time runs out while you enter the code, as others mentions there is often some leeway on the token expiry time.