2FA: App based tokens

This article describes the widely used TOTP (Time-based One-Time Passwords) based 2FA and ignores other implementation for the sake of simplicity. Wherever OTP is mentioned in the article, read it as TOTP.

You might have probably been nudged to set up two-factor authentication (2FA) for your online accounts. It could be for your social media, email, or work accounts.

Configuring 2FA typically involves these steps

• Accept that you want to configure 2FA.
• Scan the QR code using your 2FA authentication app.
• Enter the OTP code shown in the authentication app to complete the registration process.
• Download the backup codes.
• Safely keep these backup codes in your doomsday bunker.

Once you enable 2FA, you are required to present two evidences to prove your identity.

1. Something that you know.
2. Something that you have.

Your account password is something that you know and your mobile phone, in which the authentication app is installed, is something that you have.

So, you enter your password and the OTP generated by the authentication app to be able to authenticate into your account.

There is a common misconception/assumption that the authentication app knows when you are trying to sign in and generate the code accordingly.

If you open your authentication app, you can see that the code is generated irrespective of your sign in attempt. Also, you can verify that the app generates OTP code even if you disable network access or go into flight mode.

How does the authentication app work?

The QR code that you have scanned to configure the 2FA, contains four key pieces of information.

1. Secret (in base32 format)
2. Hashing algorithm. Defaults to SHA-1.
3. Validity (in seconds) of the OTP. Defaults to 30 seconds.
4. Number of digits in the OTP. Defaults to six.

Most of the service providers use defaults and only exchange secret with the QR code. If you only see a secret key being provided beneath the QR code, then you know that the other values are set to default.

There is a standard algorithm/formula that is used to generate OTP codes based on the information provided. Once the authentication app has this information, it starts to generate OTP codes. This code changes every time the validity window changes.

If the OTP validity is 30 seconds, then the code changes for every 30 seconds.

Since the provider has the information regarding our secret and other details, they can generate the code based on the shared secret and current time. Every time you enter the OTP code for verification, the provider matches this with the OTP code generated at their end. If the codes match, then the verification is successful.

Our authentication app does not communicate with the provider at all. It generates the OTP code independently of your sign-in attempts or activity. In fact, it does not have any knowledge of the provider.

Due to the network latency and request transmission time, there is a chance that the validity window shifts from the submitted code and to the moment code is generated at the provider’s end for verification.

For example, if you enter a code that is valid from 00:00:00 to 00:00:29.

• If the validation request reaches the provider before 00:00:29 for verification, then the code matches.
• If the request reaches the provider after 00:00:29, then the codes differ. Because provider calculates the code based on the time it receives the request at their end.

It might also happen that the user entered a code for future validity window w.r.t. the provider’s system time. This happens because time in your mobile might not exactly match with provider’s system time.

To avoid this problem, providers have an acceptable window. Submitted OTP code is matched against the validity windows within this acceptable window. A large acceptable window exposes a larger window for attacks. Depending on the security requirements of the provider, this acceptable window is at most one extra validity window.

Most providers accept the OTP code generated in the previous validity window as valid.

If the OTP code is constantly being rejected by the provider, it is most likely that time in your mobile is out of sync. Make sure that the device time matches with a reliable time source, such as https://time.is/.

Pros

• Since OTP generation requires no internet connectivity once the secret is shared, the app can be used offline.
• On an average, time to authenticate is faster.
• Authentication app usage does not require any personally identifiable information (PII) information to be shared.

Cons

• Secret key is stored both by user and provider. If the secret key is exposed, someone can generate the valid OTP codes at will.
• If the user’s mobile device gets stolen and the unlock pattern/passcode of your mobile is exposed, someone can gain access to the authentication app. Thus, technically speaking, an authentication app falls under the category of something that you know rather than something that you have.

Best practices

• Backup codes are a series of one-time use OTPs that can be used as a backup method for authentication if your primary authentication app is unavailable. You can use these codes only once. Hence, you should always keep your backup codes secure.
• Some authentication apps, such as authy, provide additional security features such as pin, password, or biometric authentication to protect the app itself. This can mitigate the risk of an attacker gaining access to the app if the mobile device is stolen. But, you need to make sure that this pin or password does not match with device unlock pin or password.

Additional References:

1. TOTP RFC
2. 2FA QR code generator