Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
Visit Stack Exchange
Stack Internal
Knowledge at work
Bring the best of human thought and AI automation together at your work.
Explore Stack InternalThe TOTP standardTOTP 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.
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.
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.
The TOTP standardTOTP 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.
https://datatracker.ietf.org/doc/html/rfc6238#section-5.2
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.
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.
https://datatracker.ietf.org/doc/html/rfc6238#section-5.2
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.
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.
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.
https://datatracker.ietf.org/doc/html/rfc6238#section-5.2
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.
