DUO Authenticator returns a different number than Google and Microsoft for CloudStack's TOTP.

[daviftorres]

problem

The title mentions DUO Authenticator because I want to stay consistent with the issue I already reported in DUO Security’s GitHub.

The problem occurs when setting up TOTP 2FA for a user in CloudStack. The QR code and seed work correctly in Google Authenticator, Microsoft Authenticator, and my password manager. However, DUO Authenticator generates the wrong rolling PIN (it looks out of sync).

Since the same QR code/seed works in four other apps, I believe this is a bug in DUO Authenticator. Still, since DUO is widely used as an enterprise-grade app, I wonder if CloudStack might be missing some information DUO needs when generating the TOTP.

Below are some sample TOTPs for a test user.

Revealing the Seed : LGV3KCWF3AFZKYB4MWSZBH3R6YWBINJI
QRCode content: otpauth://totp/Company:username?secret=LGV3KCWF3AFZKYB4MWSZBH3R6YWBINJI&issuer=Company

Revealing the Seed : 3JLPXCKBHYR3CHE73T7FNGBS5CDMQRBG
QRCode content: otpauth://totp/Company:username?secret=3JLPXCKBHYR3CHE73T7FNGBS5CDMQRBG&issuer=Company

versions

ACS 4.20.1

The steps to reproduce the bug

Setup TOTP on DUO and another app and compare the rolling PIN.

What to do about it?

Maybe there are optional parameters that can be provided to the Authenticator app while scanning the QRCode that would inform some missing parameters that it fails to assume.

[daviftorres]

So, for comparison I searched and found 30 QRCodes from the Internet that were in tutorials about setting up TOTP with Authenticator apps in general.

Here is what I saw:

30 out of 30 started with the appropriated otpauth://totp/ followed by a string,
30 out of 30 had the secret= attribute (no kidding),
27 out of 30 had the issuer= with a string,
9 out of 30 had the digits= (all with the most popular value of 6),
9 out of 30 had the period= (all with the most popular value of 30),
8 out of 30 had the algorithm= for the hash (seven with the default SHA1 and one with SHA256),
1 out of 30 had the endpointUrl= that I am not really sure if is standard or a feature of a password manager, for example.

The point I am trying to make here is:

• Maybe DUO's default are not what ACS expects,
• ACS could have the parameters &algorithm=SHA1&digits=6&period=30 to the QRCode generator,

Moreover, I also set many Authenticator (online and mobile apps) with the same Seed (Secret) at the same time. They often display shifted rolling pin. That explains why some SSO solutions give a grace period in case you submit the pin a few seconds after it has changed (reducing the race to type).

Eventually, they all show the same pin for a short time or commonly one (or more) is lagging behind all the others :-/

My DUO and Google Authenticator apps were alternating between the Orange and the Red from the illustration above.

Online TOTP Authenticators used (only for tests with fake/revoked seed).
https://totp.danhersam.com/
https://www.authgear.com/tools/totp-authenticator
https://auth.web.id/
https://2fasolution.com/totp.html

Can we also have a grace period that does not downgrade the security of the 2FA?

Example:

• In the first 15 seconds it would still accept the previous code,
• In the last 15 seconds it would also accept the code that will come after.

How does that sound?