Open Gummibeer opened 8 years ago
This is actually the way TOTP works. RFC 6238 extends RFC 4226 by converting a timestamp into a counter value based on a defined algorithm. The counter value will change every TIME_STEP seconds.
In practice this means the window size must be a multiple of TIME_STEP, you cannot have partial window size.
Ok, have read it a bit different but yes, After a second read it's like this. Is there another RFC for time based otp that allows a time drift in seconds unrelated to the time step?
does #9 answer your question? we have tokens that drift away from standard time (because they are cheap physical devices with an internal clock that has no way to sync with the internet)
From my understanding the window in a TOTP is also a value in seconds like the timestep - but in this package it's used as a counter window and this is something strange. For example I have a
timestep
of 30 seconds and want to allow this otp also 5secs before and after - there is no way cause the window is counter and not time based.A solution would be something like this: