TIMEOTP functionality with 2.47 - Issue with long secret

[lefjul]

I have setup TIMEOTP with 6 accounts, and this is OK for 5 of them.
Only one is not OK, strangely it is the one having the longest secret (Amazon : more than 50 characters long).
When comparing the OTP received with the one generated with my App on Android I don't get the same code.
For other accounts of course this comparaison is OK.

I tried to setup this OTP with KeepassX, this is OK. The OTP received is corresponding to the code generated on my app.

Is somebody facing the same issue (especially with Amazon or long secret) ? Have you a solution ?
Thanks for your feedback,

[Dominik Reichl]

I cannot reproduce this issue. Can you please provide example parameters?

Thanks and best regards,
Dominik

[lefjul]

I did a test :
1. Added an entry in Keepass 2.47 on my laptop as "TimeOtp-Secret-Base32" extra field with the secret (52 chars) :
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
2. Add manually in my App (Aegis) on Android phone this same TOTP (30 sec, 6 digits, SHA-1)
3. Add manually in KeepassX the same TOTP on the same laptop.
(of course times on laptop and android phone are the same).

Comparing Aegis App and KeepassX is OK : same codes are received.
Only Keepass 2.47 returns me a different code.
Maybe the secret is truncated ?

Thanks for your feedback and all your efforts on this awesome soft.

Regards,
Jul

[lefjul]

For info, I'm running on Windows 10 (ver. 1909)

[Rookiestyle]

https://tools.ietf.org/html/rfc3548#section-5
A correct base32 consists of groups of 8 characters (8, 16, 24, 32, 40, 48, 56, ...) and needs to be padded by adding = if required.
According to section 2.2 of the very same RFC and according to https://github.com/google/google-authenticator/wiki/Key-Uri-Format this padding is not required and can be omitted.

If you manually pad your 52 characters secret by adding 4 =, the result should be the same.
You can use this as a workaround until (hopefully) a new KeePass release will do this padding behind the scenes

[lefjul]

I confirm : the workaround to add 4 times "=" at the end of the 52 characters secret is OK

[Dominik Reichl]

The string
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ
is not a valid Base32 string.

The length of a valid Base32 string is always a multiple of 8 (including padding). For details, see RFC 4648 (point 6):
https://tools.ietf.org/html/rfc4648

Best regards,
Dominik

[lefjul]

The workaround given by Rookiestyle is OK. I will use it. Thanks to him.

Strange that Amazon gave me a 52 characters long secret which is indeed not a valid Base32 string.
But I notice that other softwares does the padding automatically (Aegis, Google Authenticator, KeepassXC) as explained by Rookiestyle.

It could be very interesting to add this feature in next version , I guess at least for non-technical users. Especially because nothing is reported to the user that the secret provided is not a valid Base32 string.

Regards,
Jul

[Rookiestyle]

In some circumstances, the use of padding ("=") in base-encoded data
is not required or used. In the general case, when assumptions about
the size of transported data cannot be made, padding is required to
yield correct decoded data.

Implementations MUST include appropriate pad characters at the end of
encoded data unless the specification referring to this document
explicitly states otherwise.

https://tools.ietf.org/html/rfc4648#section-3.2

I think it's not harmful to assume that TimeOtp-Secret-Base32 is a base32 string and do the padding for the next multiply of 8 characters on behalf of the user, especially since quite a lot of issuers and totp-generating apps seem to follow the otpauth way which explicitly defines the padding as optional (cf https://github.com/google/google-authenticator/wiki/Key-Uri-Format)

Might not be 100% compliant to the standard but it seems to be kind of best practice
In the worst case, minimum 9 characters would be missing and auto-padding would add only 1. As a result, the TOTP would be wrong which would be the case without padding as well.
As you can't be "more wrong" than simply being wrong, I would not consider this a big issue.

[Dominik Reichl]

Ok, I've added this now; the placeholders {HMACOTP} and {TIMEOTP} now automatically add padding to shared secrets in Base32 encoding, if necessary.

Here's the latest development snapshot for testing:
https://keepass.info/filepool/KeePass_210116.zip

Thanks and best regards,
Dominik

[Rookiestyle]

Working for me

[Dominik Reichl]

Great; thanks for testing it! :-)

[lefjul]

Tested successfully as well.
Thanks both for this,

Lefjul

[Ross Smith II]

This build fixed a TOTP generated via google-authenticator-libpam, which produced an incorrect code in KeePass 2.47, but worked in Google Authenticator, Authy, gauth, etc. Thanks for the quick fix! Please consider releasing this fix soon to help others affected by this issue.