My phone is... from the future ?

[Cozmo]

Was debating posting this here or in Software... but I will label this one as a "riddle me this, Batman"...

My phone is a Galaxy S9 (SM-G960W) with Android 10, Security Patch level Nov1-2020 (latest available).
I have many apps on my phone, namely Microsoft Authenticator and Google Authenticator.

I use MS Auth has about 20 accounts, one of which is NOT push-notification -enabled.
So when logging on to that site, I need to grab the code and authenticate. (This site also has a little link underneath the entry box where I can have that site send me a code by e-mail, more on this later...)

For the past 3 months, I login with username/password and get challenged for a code. Everything normal so far. I then enter the code and get refused, saying invalid code. "Ok, weird" I think. I fiddled around with it enough that I discovered that if I enter the code given to me via the App and get refused, I can then click the "send code by e-mail" and IMMEDIATELY click login (still with the code from the App, NOT the one in the email) - and am granted access.

( I ended up speaking with a programmer at this website, he monitored the codes I got and could confirm via the API that the code was valid).

Weird right ? Ok, park that.

I use Google Authenticator for two sites.
Site #1, I type in my username/password and get challenged. Type in my code (let's call it Code-A), refused.
Wait 30 seconds for a refresh, type in Code-B, refused.
Wait 30 seconds for a refresh, type in Code-C, refused.
Just for kicks, type in Code-A (now over a minute "old") - Access Granted ?!?!?!?

Site #2, works fine, username/password, challenge, code, access granted. Nothing to see here.

It appears my phone is providing codes that are timed somewhere in the future and I have to wait for Time to catch up ?

Any advice/ideas on this please ? I'm looking to avoid a factory reset (which I haven't done yet).

 

[AlanD]

Do you have enough access to the problem sites to check out whether their clocks are correct ( to the second)?

Alternatively, could it be that they are very busy, and whilst the code is generated, it takes a couple of seconds to update the database for the verification step.

 

[rfrazier]

@Cozmo It probably is time related. Check that auto time update via NTP is turned on on your phone and that its time is accurate. You can use time.gov as a reference. If needed, you may be able to force a time update. Otherwise, as @AlanD says, it's probably the time at the remote site. I think the authenticator system allows a fudge factor to maybe the previous or next code but someone else would have to confirm that.

May your bits be stable and your interfaces be fast. Ron

 

[PHolder]

TOTP authentication apps use the local time, on the assumption that the clock is close enough to accurate (and the further assumption that server side will have a highly accurate clock.) When you send your code to the site, the site has a certain tolerance for time slippage, maybe up to 30s or so.

Time-based one-time password - Wikipedia

en.wikipedia.org

 

[JulioHM]

Definitely a time sync issue. Make sure the device's time is synchronized and using the same timezone as the server. We've had similar issues when people manually set their clocks on their smartphones.

Not suprisingly, TOTP stands for Time-based One Time Password. The generated token depends on the actual timestamp given by the device where it is generated. The server tha validates can be configured to tolerate a gap in the clock difference, so it can vary from seconds to minutes depending on how administrators configured it.

 

[miquelfire]

Definitely a time sync issue. Make sure the device's time is synchronized and using the same timezone as the server. We've had similar issues when people manually set their clocks on their smartphones.

Not suprisingly, TOTP stands for Time-based One Time Password. The generated token depends on the actual timestamp given by the device where it is generated. The server tha validates can be configured to tolerate a gap in the clock difference, so it can vary from seconds to minutes depending on how administrators configured it.

You don't need the same timezone as the server, it just need to be set correctly so the server and client can get the same time in UTC.