Validation failure?

[haloway13]

I was able to use your tool effectively to generate a QR code that I could scan so that I could add an entry to the app. However, at https://vip.symantec.com/ I was not able to pass a test with the SYMCXXXXXXX and code being generated.

Is this expected?

[dlenski]

I was able to use your tool effectively to generate a QR code

The tool already checks the token at https://vip.symantec.com/otpCheck as part of the token-generating process:

https://github.com/dlenski/python-vipaccess/blob/3de5655c305b72b80280036ec9caf3bfda5559d2/vipaccess/__main__.py#L74-L76

Is this expected?

No.

Buggy mobile app, or timeskew on the mobile device, maybe?

[haloway13]

When using the default SYMC seed it works fine and validates. This leads me to believe the issue is elsewhere?

[dlenski]

When using the default SYMC seed it works fine and validates.

I don't know what this means. What is "the default SYMC seed"?

Please give specific examples of exactly what does or doesn't work.

[haloway13]

My assumption is that I can use the tool you have made can help me get an additional entry into the VIP Access App.

When the App first installs it gives an SYMCXXXXXXXX that works wherever I try it.

When adding an additional entry with the round + button in the lower right corner I get the second screenshot. And this is where your tool comes in. It successfully adds the new Seed(I presume it is identified with the SYMCXXXX) and starts generating codes on intervals. However, at my institutions that I try to use this when I provide the new SYMC code, I start failing with the 6 digit codes being generated.

Maybe I am off on the timing... To get the entry added to VIP Access App will being late to scan the QR code generated cause a timeskew?

[dlenski]

Frankly, I don't understand at all what you're trying to do here. Your descriptions are vague in a way that suggests that you don't have a clear understanding of how Symantec VIP credentials work, in particular how a specific credential (e.g. SYMC12345) gets associated with a particular user account for a particular institution (e.g. login dan on www.bigcorp.com).

Break your problem down into smaller pieces: start by not using the mobile app.

Generate a new credential with the command-line interface, e.g.:

vipaccess provision -p
Generating request...
Fetching provisioning response from Symantec server...
Getting token from response...
Decrypting token...
Checking token against Symantec server...
Credential created successfully:
    otpauth://totp/VIP%20Access:SYMC25548149?secret=PJPY3J734IEOXR4Y7AKYYEIS4H6SNZZW&digits=6&algorithm=SHA1&image=https%3A%2F%2Fraw.githubusercontent.com%2Fdlenski%2Fpython-vipaccess%2Fmaster%2Fvipaccess.png&period=30
This credential expires on this date: 2027-07-30T17:28:00.348Z

You will need the ID to register this credential: SYMC25548149

You can use oathtool to generate the same OTP codes
as would be produced by the official VIP Access apps:

    oathtool    -b --totp PJPY3J734IEOXR4Y7AKYYEIS4H6SNZZW  # output one code
    oathtool -v -b --totp PJPY3J734IEOXR4Y7AKYYEIS4H6SNZZW  # ... with extra information

Then try to associate this with your institutional account. Then try to login, using the oathtool commands to generate the login codes. If that doesn't work, loading the credential into some other mobile authenticator app also isn't going to work. If that does work, then it should also work when correctly loaded into a TOTP-compatible authenticator app.

[dlenski]

Maybe I am off on the timing... To get the entry added to VIP Access App will being late to scan the QR code generated cause a timeskew?

To this question, I can give a definitive answer: no.

(When you load the credential into any particular device or app) has no effect on the time skew.

The only thing that can cause a time skew is if the device itself has a clock relative to the server in terms of seconds elapsed since 1970-01-01T00:00:00+00:00.

[haloway13]

[haloway13]

As seen by the previous image I used the tool correctly?

[dlenski]

As seen by the previous image I used the tool correctly?

This screenshot does not clarify anything for me.

Do you understand what I meant by this 👇 from my previous comment?

suggests that you don't have a clear understanding of how Symantec VIP credentials work, in particular how a specific credential (e.g. SYMC12345) gets associated with a particular user account for a particular institution (e.g. login dan on www.bigcorp.com).

After generating a new token with vipaccess provision, you need to tell your institution to associate that token with your account. That process is completely institution-dependent.

Are you sure you are doing that correctly before attempting to use the newly-generated token?

If you are trying to do an on-line verification of the token, the "Test" button on the https://vip.symantec.com homepage is broken; you need to use https://vip.symantec.com/otpCheck in order to get a human-readable response:

[haloway13]

I really appreciate the patience you are exhibiting weith me.

I can definitively say that the command line tool works and generates appropriate 6 digit codes because I do succeed at the test at https://vip.symantec.com/otpCheck

I can even register the new code at my institution and use the command line tool to generate a new 6 digit code.

The issue is directly related to adding a new QR/App Code to the Symantec VIP app using the command below where I substitute the XXXX and YYYY information appropriately.

$ qrencode -t UTF8 'otpauth://totp/VIP%20Access:SYMCXXXX?secret=YYYY&issuer=Symantec&algorithm=SHA1&digits=6'

The 6 digit codes then generated by the app are off compared to what is generated at the command line.

I would appreciate guidance as to how to troubleshoot why this is not working properly.

Thanks!

[haloway13]

I got it to work.

I was not sending the correct otpauth string. I thought I only had to substitute the SYMC code and Secret (6 digit code)

When in fact it is not the 6 digit code, it is the 32 character secret.

I appreciate your help.

[dlenski]

I was not sending the correct otpauth string. I thought I only had to substitute the SYMC code and Secret (6 digit code)

I'm glad it's working now.

Is there a reason why you weren't using the 'otpauth://' URI verbatim from the output of vipaccess provision?

[haloway13]

I would say that the XXXX as a stand-in for the digits of the SYMC and the YYYY as the stand-in was deceiving. Maybe something more along the lines of:

qrencode -t UTF8 'otpauth://totp/VIP%20Access:<_SYMC_ID>?secret=<full_otpauth_string>&issuer=Symantec&algorithm=SHA1&digits=6'

where <_SYMCID> = SYMCXXXXXXXX in the example and = XXXXXXXXXXXX in the example

might be more direct?