Outputs are not correct

[ph1234k]

This outputs a 6 digit passcode (only after some modification to align types), however the passcode is not usable.

After extensive modification, nothing I have tried nor the original script produce values that can actually be used.

[datr]

Hey ph1234k,

Can you expand on what you mean by used?

I've just tried comparing the output against the Android version and it seemed to match. Here our the steps I tried:

1) Create a new token in the Android MobilePASS App. 2) Choose 'Activate' and 'Manual Enrolment'. 3) Leave the policy string blank. 4) Copy the activation code into the python script. 5) Set a PIN to whatever you want (it isn't used to generate the OTP). 6) Compare the outputs of the app and the script.

In my case these were the same. Can you let me know what you tried?

[chased316]

@datr We've got this system in corporate with the policy string required. I'm not sure where the policy string is used, but currently the values we get don't match the mobilepass client. Our OTP's are still 6 digits, here's an example:

#if name == 'main':
# key = "SEJUQ-KYURW-IMF7L-UDAFL"
# policy = "42962449345"
# index = 0
#print generate_mobilepass_token(key, index, policy) # 641533

[chased316]

@datr So I noticed in the client that if you don't have a policy number, you're required to have a pin. Maybe again this data is used for locally decrypting the OTP or creating the key?

[datr]

@chased316 So it looks like the policy string affects how the key is supposed to be processed.

When there's no policy, a "legacy key" is used -- which is what is implemented now. Each 5th character in the code is used as a checksum but doesn't contribute to the value.

However, in your example there's no checksums and all the characters should be used to build the key.

I'm currently working on implementing a fix. I'll hopefully have something soon.

[chased316]

@datr Interesting! All of my testing was presuming that our key was still 32 bits of legit data with 2 bits of checksum data salted every 8 bits as you described. I didn't ever try/think to reverse engineer the checksum assertion you had made. Please feel free to update here if there's any additional data that may help you figure it out, I'm scratching my head at this point ;)

[ph1234k]

Sorry for the late reply, as @chased316 mentioned, we do require a policy string and when we have one set and use the MobilePASS client generate a key, this key does not match the script output using a matching policy and activation key (even though it is easy to guess which index would be used, in my tests I generated indexes 0 - 9,999 in case the client started at an index other than 0 for some reason). Thank you for your response.

[datr]

@chased316 I've just pushed an update which should correctly compute the OTP in your example. Can you give it a go and let me know if it's working for you?

[chased316]

Checking this now. @datr

[chased316]

@datr. SUCCESS! Thank you very much :D Edit: I tested this against the production OTP environment and is definitely generating the correct codes. Thanks again :dancers:

[datr]

Excellent. I'll mark this as closed then. :)