The Authenticator apps (ex-Google Authenticator, Okta, LastPass etc), as you are all aware, can be used to obtain verification codes for any of your accounts that utilize MFA (Multi-Factor Authentication). You must scan the QR code in your MFA settings for any third-party provider to create an account. Once this is set up, a special code that can be used for MFA is created.
Have you ever wondered
How an app can function normally even without an internet connection or how the code created offline may be utilised for MFA?
How does the server verify the code generated by the client (Authenticator apps)?
What does the QR code that we scan to create the account serve as? What happens when a QR code is scanned?
You are in the right place if you have any of these questions. We shall try to understand what goes on behind the scenes in this blog. Let's get going.
Breaking Down QR Code
In Layman's terms, a QR code is just a collection of data that is shown as a sequence of pixels in a grid-like square.
Let's now try to connect this to our use case. So there is some information that is eventually contained in the QR code that we scan. But what exactly is that information?
When you scan the above QR code you will find the below information,
otpauth://totp/Google:ozil@test.com?secret=I5KESRBZIRAUEQ3VIVHG2TSUMQ4TM6DZ&digits=6&algorithm=SHA1&issuer=Google&period=30
It is a URI in the format, otpauth://TYPE/LABEL?PARAMETERS.
This documentation on GitHub explains the construction of the above URI.
Here in our example, it says to provision a TOTP key for user ozil@test.com, to use with a service provided by Google. It also provides additional parameters like the size of the code to be generated (number of digits), the algorithm and the period to generate the new code.
What are HOTP and TOTP?
HOTP - HMAC-based one-time password.
TOTP - Time-based one-time password.
Before looking into the detail of HOTP and TOTP, let us try to understand what is HMAC.
HMAC - Hash-Based Message Authentication Codes
Let us try to understand with an example,
Alice wants to send a file to Bob. But a vicious attacker can intercept the file and send some malicious files.
Alice and Bob want to make sure that the file that they transfer should not be intercepted and tampered with by the man in the middle. so they decided to agree on a secure hash algorithm. Alice sends the checksum (Hash of file) along with the file transferred. Bob on the receiving end verifies the checksum by computing the hash of the received file manually with the checksum sent by Alice.
Awesome !!!, via this Bob can ensure the integrity of the file.
But not so fast? What about the authenticity of the file? The attacker can still tamper the file and send the new checksums instead of the original checksums, and here Bob will never know the difference.
HMAC to rescue!!!!!
With HMAC both Alice and Bob agree on a shared key beforehand.
Now Alice runs a cryptographic hash function over the file to be transferred and a shared secret key and sends it along with the file. Bob on the receiving end does the same and verifies the authenticity of the file shared by Alice.
Here though the attacker can tamper with the file, the attacker doesn't know the key to create the correct checksum that will pass the verification by Bob.
HMAC stands for Keyed-Hashing for Message Authentication. It's a message authentication code obtained by running a cryptographic hash function (like MD5, SHA1, and SHA256 etc) over the data (to be authenticated) and a shared secret key. HMAC is specified in RFC 2104.
HOTP - HMAC Based One Time Password
The HMAC-based One-Time Password or HOTP is an event-based OTP algorithm that makes use of a variable counter and a shared secret key to generate a passcode based on this algorithm. The counter is naturally synchronised when the account is set up, both client (Authenticator Apps) and the server keep track of the counter and have a copy of the shared key.
As you can see in the above diagram, the hashed output is obtained by running a cryptographic hash function over the counter and a shared secret key. The hashed output here is a fixed length of characters which is too big. It is then truncated into the desired length and we get the final passcode.
The counter at the client side is increased when the button is clicked and the counter at the server side increases on successful validation of the code.
what happens if the button is clicked by the client multiple times without successful validation? How does it work then?
As the Server keeps track of the current counter value, When the server receives a new request to validate the OTP, it validates the code by using the current counter value. If it fails it also has some look-ahead window and it will use the subsequent counter value until the look-ahead window is reached. If the code matches within this lookahead window, then the request succeeds and the server increases the counter to it. If the code doesn't match within the lookahead window then the request fails.
This is also one of the disadvantages of the HOTP. If this counter value is manipulated on the client side and is far ahead of the look-ahead window of the server side, then no request succeeds. The only way is to reset the MFA config.
One another disadvantage is that the code generated is long-lived, it is valid until successful validation on the server side or until new code is generated on the client side.
TOTP - Time-Based One-Time Password
Time-based One-Time Passwords, or TOTP, is another type of two-factor authentication (2FA). It works similarly to HOTP, the only difference is it uses the current time as input instead of the counter value and generates a passcode based on this algorithm.
As you can see in the above diagram, the hashed output is obtained by running a cryptographic hash function over the current time (Ct) and a shared secret key. The hashed output here is a fixed length of characters which is too big. It is then truncated into the desired length and we get the final passcode.
Ct = current time i.e, in Unix time epoch (seconds that have elapsed since Jan 01 1970) / lifetime of the passcode (period, 30s, 60s etc)
Similar to the look-ahead window in HOTP, here in TOTP the server supports a certain level of discrepancy in the validation since the passcode reaching the server depends on certain external factors like internet connection etc
The main advantage of TOTP is the passcode is short-lived, and the client and the server have better synchronization since both depend on time.
And now we are almost at the end and let's revisit the questions that we had earlier,
Have you ever wondered how an app can function normally even without an internet connection or how the code created offline may be utilised for MFA?
How does the server verify the code generated by the client (Authenticator apps)?
What does the QR code that we scan to create the account serve as? What occurs when a QR code is scanned?
Let's try to answer this now,
Neither the inputs nor the calculation requires internet connectivity to generate or verify a token. Thus users can use authenticator apps while offline
Both client and server follow a specific standard to produce/verify a passcode.
QR code contains the details from the server like which key to use, who is the issuer, type, algorithm etc.
I hope this would have been helpful for you to understand what is happening behind the MFA apps and one-time passcode. I welcome you to drop a comment if you have any questions or suggestions. Thank you!!!