Cannot register token if token begins with '\x21\x10'

[weeebdev]

Surprisingly, my token that works on the FortToken after b32decode begins with \x21\x10 and is unable to register with the following error:

{'error_code': 40, 'error_message': 'FTM token Activation Code is invalid'}

[randomstuff]

The \x10 probably represents different TOTP parameters or maybe a different key "encryption" method. I messed around with the different parameters (mostly the hash method) without success for now.

[randomstuff]

According to denngie/fortitoken-decrypt some token would use SHA1 but with a time step of 60s instead of 30s (which is the default and what is used in this script).

[Zasch]

Is there a way to set it to a time step of 60s?

[randomstuff]

Most HOTP/TOTP programs can used a custom time step parameter:

• For oathtool, this is -s 60.
• For otpauth URIs (and QR codes), this is ...&period=60.

Note that I do not know if this fixes the issue. Maybe this parameter does not apply based for this version and maybe other things have to be changed (such as the secret derivation mechanism, the hash algorithm, etc).

[ddoomenbsu]

According to denngie/fortitoken-decrypt some token would use SHA1 but with a time step of 60s instead of 30s (which is the default and what is used in this script).

Is there a way to test if this works (by altering the script to use 60s when 'begins with \x21\x10' is not true)?

[randomstuff]

After checking the error and the code, I'm not sure this issue is actually the same that I had so I don't believe my comments are relevant for this error.

[ss23]

If anyone is able to share information on how they got a token that is considered invalid (such that I can try get one myself), I am happy to take a look and try figure out what is going on. Without this, it is difficult to understand what is different about the different versions, but it's probably a simple change, just difficult to determine without seeing an example (or reversing the mobile application).

[weeebdev]

Apologies.
I completely forgot about this issue. Later in the day, I was able to retrieve the token and generate totp. I don't really remember which tool I used and how I did that tho.
You can close the issue if this became irrelevant

[randomstuff]

I was able to retrieve the token and generate totp.

Having more information about this would be quite interesting :)

[ddoomenbsu]

Problem for me was that the token was registered by a colleague of mine around the same time, but he was faster :)

[weeebdev]

I was able to retrieve the token and generate totp.

Having more information about this would be quite interesting :)

I wish I remembered. Just spent an hour trying to figure out how I managed to do that, but nothing came to mind. But the issue is repeatable with the following token: "EEIHVK54DDCWV55A" (this is the expired one, so I think it should be safe to share)

Most HOTP/TOTP programs can used a custom time step parameter:

• For oathtool, this is -s 60.
• For otpauth URIs (and QR codes), this is ...&period=60.

Note that I do not know if this fixes the issue. Maybe this parameter does not apply based for this version and maybe other things have to be changed (such as the secret derivation mechanism, the hash algorithm, etc).

This was exactly the case for me! Spent a lot of time with this.