We RECOMMEND that at most one time step is allowed as the network delay. Gitlab (one service, but thanks to subdomains and hosting options is actually 3 instances for me)īut, reading that spec, it looks like Duo and all of those services are all following the spec:.So far I’ve been able to reproduce this with high reliability (not 100%, likely due to accounting for time drift, but quite often) on: Relatively few services, but they’re also the services I have to use TOTP frequently for and don’t have a better alternative, like Duo integration or WebAuthN. I’d be curious to know which service you were authenticating against where this wasn’t the case. Is there perhaps something I’ve done wrong?
So it seems like Duo Mobile is correctly generating the TOTP code based on the current time, but it’s incorrectly determining how much time is left before that code needs to be regenerated. And when Duo Mobile gets to the end of its 30-second countdown the TOTP code changes to match 1Password and Google Authenticator. Log in with the 1Password/Google Authenticator code and it works. I waited until 1Password and Google Authenticator changed the displayed TOTP code, tried to use the code shown in Duo (which matches the code previously shown by 1Password and Google Authenticator), and it failed as an incorrect token. All three showed the same TOTP value initially, but if I generate a TOTP code in the middle of a time interval (the standard is 30 seconds, so wait until say 15 or 45 seconds past the minute) 1Password and Google Authenticator show I have just a few seconds left while Duo Mobile says I have the full 30 seconds. To test, I took a TOTP seed for one service and added it to Duo Mobile, 1Password, and Google Authenticator. I’ve had some problems using Duo-generated TOTP tokens and it looks like Duo Mobile isn’t properly considering the time when calculating how much time is left for the TOTP token.
0 kommentar(er)
