9/22/2023 0 Comments Vip access app totp![]() For everyone’s sanity, let’s not be as lax as the Symantec server is: 7a979c42bc6845cca68db9b4d0c58fae13b9f7b9Īnyway, I discovered that the VM’s clock lagged the other systems by around 88 seconds. So that explains how/why your 88-second skew accepted initially. " (check your system time it differs from the server's by %d seconds)\n" % otp_token,Īnd what I find is… you have to put in an offset of about ☓000 seconds (50 minutes… □ ❗) before the server won’t just “accept” your time skew, and “bake it in” to the newly-created token. Print("WARNING: Something went wrong-the token could not be validated.\n", + if not vp.check_token(otp_token, otp_secret, session, timestamp=time.time() + OFFSET_GOES_HERE): if not vp.check_token(otp_token, otp_secret, session): Print("Checking token against Symantec server.") Otp_secret_b32 = base64.b32encode(otp_secret).upper().decode('ascii') Otp_secret = vp.decrypt_key(otp_token, otp_token) 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 So how could it have succeeded when you ran it⁉️ It should not succeed if the clock is >30 seconds off. I created my credential using vipaccess provision on a VM whose clock was 88 seconds behindĪs of d4c618c4a8f000dc3f1e6d57fa764bb96abe455e, vipaccess provision is supposed to warn you if the clock is skewed. Can anybody shed light on this for me? □ 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. So… Google Authenticator and 1Password show the ‘wrong’ codes for the same secret compared to oathtool and vipaccess show. Then I discovered that this command generates correct TOTP codes: $ oathtool -b -totp YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY ![]() Interesting! Initially, I thought this might have something to do with issue #39. 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.Īs 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. ![]() 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. And eureka-it worked!Īfterwards, I used this command to generate a QR code for Google Authenticator: $ qrencode -t utf8 $(vipaccess uri | grep otpauth) I did so, and when prompted for the TOTP code, I used the output from vipaccess show. 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 just added 2FA with one of my providers using python-vipaccess instead of the Symantec app. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |