Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

totp to expire with step config after generation #697

Open
surajk-TDM opened this issue Mar 7, 2023 · 4 comments
Open

totp to expire with step config after generation #697

surajk-TDM opened this issue Mar 7, 2023 · 4 comments

Comments

@surajk-TDM
Copy link

Currently we observed that, whenever we generate a totp, the step config configured (say 30 seconds) . The totp expires on the 30th second. say if XXXXXX is totp generated at 12:00:15, expires at 12:00:30. Instead , totp generated at 12:00:15 to be expired at 12:00:45.

@lpavliuk
Copy link

The Time-Based Algorithms work this way. It doesn't mean that the code's 30-second life starts from the time when it is generated. It means that it complies with the 30-second TOTP RFC 6238 algorithm. Otherwise, you would not have been able to generate the same time-based codes in different devices as they had been generated at different times.

@Lerado
Copy link

Lerado commented Jul 28, 2023

The Time-Based Algorithms work this way. It doesn't mean that the code's 30-second life starts from the time when it is generated. It means that it complies with the 30-second TOTP RFC 6238 algorithm. Otherwise, you would not have been able to generate the same time-based codes in different devices as they had been generated at different times.

You mean in that case any generated totp within 12:00 and 12:30 (excluded) will expire at 12:30 ?

@lpavliuk
Copy link

@Lerado correct!

@Lerado
Copy link

Lerado commented Jul 28, 2023

@Lerado correct!

Thank you ! According to the RFC it's recommended to consider having an acceptable delay of transmission that could be considered valid. At most one time-step backwards is recommended.

So considering T1 and T2 two consecutive timesteps, any token generated within T1 but checked with T2 could be considered valid according to RFC 6238.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants