Google Authenticator generates different TOTP codes than vipaccess show/oathtool?

I just added 2FA with one of my providers using python-vipaccess instead of the Symantec app. While on the phone with their support rep, he asked me to confirm that I could log out and then log back in again before ending the call. I did so, and when prompted for the TOTP code, I used the output from vipaccess show. And eureka—it worked!

Afterwards, I used this command to generate a QR code for Google Authenticator:

$ qrencode -t utf8 $(vipaccess uri | grep otpauth)

I was able to import it successfully using the QR code, but I was disappointed to discover that it generates a different TOTP code than vipaccess show. Thinking perhaps it was a problem with the QR-code generation step, I tried manually entering the 32-character ‘secret’ portion from the output of vipaccess uri into Google Authenticator, and discovered that it generates the exact same (incorrect) TOTP codes as the QR code did.

As a further test, I entered the same secret into the 1Password app (which was my end goal all along) and saw that it generates the same (wrong) codes as Google Authenticator. Interesting! Initially, I thought this might have something to do with issue #39. Then I discovered that this command generates correct TOTP codes:

$ oathtool -b --totp YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY

So… Google Authenticator and 1Password show the ‘wrong’ codes for the same secret compared to oathtool and vipaccess show. That feels… like user error on my part(?) I suspect I’m about to learn something new/important about TOTPs, but I’ve no idea what that is yet. Can anybody shed light on this for me? 😕

[dlenski]

I created my credential using vipaccess provision on a VM whose clock was 88 seconds behind

As of d4c618c4a8f000dc3f1e6d57fa764bb96abe455e, vipaccess provision is supposed to warn you if the clock is skewed. It should not succeed if the clock is >30 seconds off.

So how could it have succeeded when you ran it⁉️

Well, I tried to figure this out, by kludging in various time offsets when validating the newly created token, which should cause the validation to fail…

diff --git a/vipaccess/__main__.py b/vipaccess/__main__.py
index 33826d1..03d2bee 100644
--- a/vipaccess/__main__.py
+++ b/vipaccess/__main__.py
@@ -55,10 +55,12 @@ def provision(p, args):
     otp_secret = vp.decrypt_key(otp_token['iv'], otp_token['cipher'])
     otp_secret_b32 = base64.b32encode(otp_secret).upper().decode('ascii')
     print("Checking token against Symantec server...")
-    if not vp.check_token(otp_token, otp_secret, session):
+    if not vp.check_token(otp_token, otp_secret, session, timestamp=time.time() + OFFSET_GOES_HERE):
         print("WARNING: Something went wrong--the token could not be validated.\n",
               "    (check your system time; it differs from the server's by %d seconds)\n" % otp_token['timeskew'],
               file=sys.stderr)

And what I find is… you have to put in an offset of about ±3000 seconds (50 minutes… 😱 ❗) before the server won’t just “accept” your time skew, and “bake it in” to the newly-created token. Woof. 👎 👎

So that explains how/why your 88-second skew accepted initially. For everyone’s sanity, let’s not be as lax as the Symantec server is: 7a979c42bc6845cca68db9b4d0c58fae13b9f7b9

[dlenski]

Anyway, I discovered that the VM’s clock lagged the other systems by around 88 seconds.

Ding ding ding 😉

Note that there’s a vipaccess check, which will check whether the token is in-sync with Symantec’s servers. (Which may not have helped in this case, because it seems you managed to register your token with an off-by-88-seconds clock, thus likely baking in the off-by-88-seconds interval.)

I always just kind of assumed that Google, Github and other providers used some kind of ‘grace window’ around the current time, and would honor a provided token if it was one or two ‘slots’ ahead or behind the current time, i.e., “Well, this token isn’t currently valid, but it [would have been | will be ] 90 seconds [ago | from now], so we’ll just wave it through.” Symantec seems to handle this a little bit differently(??)

Yeah, there may be. If you (consistently?) give them codes that are off by ±1 period, they may decide that your system clock is shifted, and start expecting you to give them codes that are off by that amount.

Servers that use hardware tokens definitely have to do this, because a hardware token may drift by a substantial fraction of the period during its battery lifetime of 5-10 years.

Your “wild speculation” seems about right.