How Google Authenticator, HMAC-Based One-time Password, and Time-based One-time Password Work
It has been known that passwords are not good enough. Multi-factor authentication (MFA) adds extra levels of defense by asking the user to provide additional pieces of information apart from the password. There are the main three categories of information:
- Something you know: Password, security questions, PINs
- Something you have: Things in the users’ possession, e.g., smartphones, hardware tokens
- Something you are: Things that prove the user is the person they claim to be — usually biometric factors (Fingerprint, Face ID, etc.)
A lot of websites provide 2FA by taking the password as the “something you know” and the token generated by the authenticator as the “something you have”. Indeed, if you use the authenticator app on your smartphone you may also get the third factor for free, by needing to pass your smartphone’s biometric authentication before launching the authenticator app.
Some password managers like LastPass and BitWarden provide authenticator functionality as well. I think it is a terrible idea to use them, you are basically collapsing all the factors back into one — your master password.
Are all authenticators created equal?
When you enable two-factor authentication on websites, they usually show you a QR code and ask you to scan and launch your authenticator app. Some sites specifically ask you to use Google Authenticator, you don’t have to. What Google Authenticator uses are the HMAC-Based One-time Password (HOTP) and Time-based One-time Password (TOTP) algorithms. Other authenticator apps like Authy, Duo Mobile, Lastpass, and 1Password all implement the same algorithms and are able to generate the exact same tokens you get from Google Authenticator.
The major difference among different authenticators is that some integrate with the cloud and upload an encrypted copy of your keys to their server, so you enjoy the convenience of accessing your tokens on multiple devices. Of course, in this case, you are also putting trust on the authenticator provider.
What is the magic behind the QR code?
The QR code is actually a URI. The one in above screenshot is
otpauth://totp/Autodesk?secret=KFTDKTSKGNHTC2JVThe otpauth:// URI scheme is originally formalised by Google. Most authenticator apps register a handler for otpauth:// so the camera app knows how to prompt the user to launch the authenticator app when it’s scanned. This documentation on GitHub explains the construction of the URI:
otpauth://TYPE/LABEL?PARAMETERSTYPE is either HOTP or TOTP (more on this later). LABEL is for display only, it’s used by the authenticator app to pre-populate the name of the account. secret is the key used by the authenticator to generate the token.
Although the URI scheme itself supports different PARAMETERS like Algorithm and Digits, the Google Authenticator does not implement them and most websites assume the default, using SHA1 and 6-digit token.
HOTP and TOTP
Google Authenticator support two types of algorithms.
- HMAC-Based One-time Password (HOTP)
- Time-based One-time Password (TOTP)
Here, the one-time password is the 6-digit token that the user sends to the website to get validated. The secret key is provided by the website to the user in the QR code, both sides need to retain this secret key for one-time password generation (this key is stored within the authenticator).
One key requirement for the one-time password is that each password should be used once only — the algorithm therefore needs some kind of variable element to generate a different OTP each time the user wants to log in.
In HOTP, that variable is a counter. The server and user calculate the OTP by applying a hashing and truncating operation to the secret key and the counter. The server compares the OTP it calculated against the one provided by the user. Both sides then increment the counters.
An obvious drawback of HOTP is that the counters have to be kept in sync between the server and the user. If a user opens the authenticator app to generate an OTP but ends up not using it, the counter on the user side will become out of sync with the server. One way to handle this is a resynchronisation mechanism in which the server tries a couple of future counter values to see if it finds a matching OTP and synchronise the counter accordingly.
TOTP improves HOTP by using the current time as the variable element. In TOTP, the time is defined as the number of seconds since Epoch divided by a period (30 seconds in most implementations). As long as the clocks on the user device and the server are accurate, they will be able to generate the same OTP together.
There is still an edge case though. There is a gap in time between the user OTP generation and the server OTP generation. The server generates OTP based on the time when the OTP from the user reaches the server. Given some unknown message transit time and clock drift between the user device and the server, it’s possible that the time used in the user’s calculation belongs to a different time step (30s period) from the one used by the server. The solution to this is usually for the server to accept OTP calculated using one time step forward or backward.
Have you ever waited for the next token to appear when it’s expiring in a few seconds, fearing that you won’t have enough time to enter it to the textbox? You probably don’t need to, since the server usually accepts both the new one and old one if the time difference is not too much.
Most websites use the TOTP algorithm and all Google Authenticator compatible alternatives on the market support the same. If you are advanturous, you can also implement your own TOTP generator, you will get the exact same 6-digit token as Google Authenticator if you do it correctly.
Simple implementations of HOTP and TOTP:
Hope you enjoyed the story!
