BLOG POSTS
Mobile Authenticator Apps Algorithm Support Review - 2023 Edition
By Laban Sköllermark (@LabanSkoller)
Last week my favorite IT security podcast Bli säker (Become Secure in English) published the episode The Epochalypse and the QR Code (only in Swedish) where they explained the techonology behind mobile authenticator apps. I felt I needed to refresh my TOTP algorithm support investigation from 2019 before the recording of the next episode of the Bli säker podcast. :)
So this is an update to the blog post I published in July 2019 called Many Common Mobile Authenticator Apps Accept QR Codes for Modes They Don’t Support. Most of the text, like an introduction to the concepts, is copied here so there is no need to revisit unless you are interested in the apps’ support back then. If you’ve recently read it or you are just interested in the results in this 2023 edition, you might want to skip to the Tested Apps section. This year I don’t write comments on the individual apps and I don’t include any screenshots. See the old blog post for such details. Not much has changed in the tested apps since then. This year I’ve included seven (7) new apps however.
You probably use an “authenticator app” such as Google Authenticator to enable two-step verification (sometimes called two-factor authentication, 2FA, or multi-factor authentication, MFA) for an online account. The method is called Time-Based One-Time Password Algorithm (TOTP) and is standardized in
I have compared the following TOTP apps for the mobile platforms Android and iOS:
- Aegis (Android only)
- Bitwarden Password Manager (required premium account for TOTP support)
- Dashlane Authenticator
- Duo Mobile
- FortiToken Mobile
- Google Authenticator
- LastPass Authenticator
- Microsoft Authenticator
- Okta Verify
- Oracle Mobile Authenticator
- Raivo OTP (iOS only)
- Salesforce Authenticator
- Sophos Authenticator
- Symantec VIP Access
- Twilio Authy
- Yubico Authenticator
Introduction and Conclusion
The de-facto standard is to transfer TOTP parameters including the secret (key) using a QR code. It seems Google invented this method. The QR code encodes text on the so called Key URI format as per a Google Authenticator wiki article:
otpauth://totp/ACME%20Co:john.doe@email.com?secret=HXDMVJECJJWSRB3HWIZR4IFUGFTMXBOZ&issuer=ACME%20Co&algorithm=SHA1&digits=6&period=30
The TOTP standard recommends a default time-step size of 30 seconds. Many apps support 60 seconds as well. The HMAC-SHA-1 hash function is the default but HMAC-SHA-256 and HMAC-SHA-512 are also allowed. The Key URI format says
The digits parameter may have the values 6 or 8, and determines how long of a one-time passcode to display to the user. The default is 6.
Varying the number of digits is not mentioned in the TOTP standard apart from in the Java reference implementation, but it’s mentioned as an extension in the underlying HMAC-Based One-Time Password Algorithm (HOTP) standard (
A simple enhancement in terms of security would be to extract more digits from the HMAC-SHA-1 value. For instance, calculating the HOTP value modulo 10^8 to build an 8-digit HOTP value would reduce the probability of success of the adversary from sv/10^6 to sv/10^8.
My investigations show that many common mobile authenticator apps accept QR codes for hash algorithms, periods and number of digits they don’t support. Instead they assume the standard settings and generate tokens based on that, giving wrong tokens, no error messages and a bad user experience. Sites providing TOTP as a two-step verification method usually require the user to provide one token to prove that it has saved the TOTP parameters, the device has correct time and so on so there is no risk that these shortcomings would lock out users from their accounts, but there is a risk that a user would skip two-step verification if the setup process fails.
Recommendation to App Developers
I recommend authenticator app developers to validate the data from the QR code, check if the app supports the mode encoded in it and give the user a descriptive error message if it detects a setting which the app does not support. Even better would be to add support for all three SHA hash algorithms mentioned in the TOTP RFC (HMAC-SHA-1, HMAC-SHA-256 and HMAC-SHA-512), 6 and 8 digit tokens plus 30 and 60 second periods.
Recommendation to Site Owners
For sites choosing to let users protect their accounts with two-step verification via TOTP I recommend sticking to the HMAC-SHA-1 algorithm, 6 digits and a period of 30 seconds, at least as a default value, since this is currently the only mode all tested apps support. Choosing another mode is begging for problems for the users unless a list of compatible apps is presented to the user.
Tested Apps
The following table shows which apps I’ve tested on the two platforms and the versions. Links go to Google Play and Apple App Store.
| Legend | |
|---|---|
 |
All tested modes supported |
 |
Only some modes supported but error messages on the others |
 |
Wrong tokens displayed for unsupported modes |
Generation of Test QR Codes
In order to test the different apps I chose to generate a set of QR codes with different modes, scan them with all tested apps and then compare the generated TOTP codes with the output of oathtool below.
I know that the secrets below should be longer for HMAC-SHA-256 (32 bytes) and HMAC-SHA-512 (64 bytes) than for HMAC-SHA-1 (the HOTP RFC recommends 20 bytes), but it doesn’t matter since the Keyed-Hashing for Message Authentication (HMAC)
The following Bash for loop was used to produce the QR codes in PNG format using qrencode 3.4.4 (man page):
$ for algorithm in SHA1 SHA256 SHA512
> do
> for digits in 6 8
> do
> for period in 30 60
> do
> qrencode -o "AA_${algorithm}_${digits}_${period}s.png" \
> "otpauth://totp/labanskoller.se:AA_${algorithm}_${digits}dig_${period}s@labanskoller.se?algorithm=${algorithm}&digits=${digits}&issuer=labanskoller.se&period=${period}&secret=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
> done
> done
> done
Resulting 12 QR codes:
Generation of Tokens to Compare With
The correct tokens to check against were produced with oathtool 2.6.7 (man page):
$ for algorithm in SHA1 SHA256 SHA512
> do
> for digits in 6 8
> do
> for period in 30 60
> do
> printf "%-18s: " "AA_${algorithm}_${digits}dig_${period}s"
> oathtool --base32 --totp="${algorithm,,}" \
> --time-step-size "${period}" \
> --digits "${digits}" \
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> done
> done
> done
AA_SHA1_6dig_30s : 148285
AA_SHA1_6dig_60s : 512776
AA_SHA1_8dig_30s : 11148285
AA_SHA1_8dig_60s : 21512776
AA_SHA256_6dig_30s: 155759
AA_SHA256_6dig_60s: 202695
AA_SHA256_8dig_30s: 28155759
AA_SHA256_8dig_60s: 69202695
AA_SHA512_6dig_30s: 389950
AA_SHA512_6dig_60s: 246498
AA_SHA512_8dig_30s: 22389950
AA_SHA512_8dig_60s: 86246498
Summary
Many common mobile authenticator apps accept QR codes for hash algorithms, periods and number of digits they don’t support. They give wrong tokens, no error messages and therefore a bad user experience. I urge TOTP app developers to validate the data that comes from the scanned QR codes and present the user with a descriptive error message if they choose to not support all possible modes. I recommend site owners who support two-step verification using TOTP to give users guidelines on which apps to use if they choose a mode other than the most common HMAC-SHA1 algorithm, 6 digits and a period of 30 seconds.
This year when I included many new apps there were several with full support for all tested TOTP variations, so I won’t crown the best ones.
Comments?
Do you have questions, comments or corrections? Please interact with the toot, tweet, LinkedIn post or make a pull request.
Credit
- Icons made by Smashicons from www.flaticon.com licensed by CC 3.0 BY.
- Thanks to Karl Emil Nikka for bringing up the TOTP subject in his podcast so I felt urged to refresh my old blog post.
- Thanks to Benjamin Björk for pointing out a spelling mistake (corrected 2023-MAR-22).