How authenticator apps work and what alternatives there are to Google Authenticator.

Many online services allow (and sometimes even require) you to set up two-factor authentication (2FA) with one-time codes. Google Authenticator is the most well-known and widely used authenticator app that generates such codes. Almost all services are compatible with it, and some even provide a link to the app when you set up 2FA. But is Google Authenticator the only option, or should you give one of the many alternatives — like Microsoft Authenticator or Twilio Authy — a whirl?

Since these alternatives exist and clearly have a userbase, you might assume they could be full-fledged replacements for Google Authenticator. But what, if any, are the pitfalls? For those who have no time to read to the end, here’s the answer straight away: don’t worry, Google Authenticator is more than replaceable. But if you’re curious about the whats, whys, and hows — read on…

How authenticators work

Let’s start with how authenticator apps work in general. Several open standards for strong authentication have been created under the umbrella of the Initiative for Open Authentication (OATH). Authenticator apps are based on these standards (along with some other things, but which aren’t the topic of this post).

OATH HOTP

Way back in 2005, the OATH HOTP (hash-based one-time password) authentication standard appeared. This laid down the fundamentals of authentication using one-time codes that are synchronously generated on the client and server sides.

The idea is that both the app and the service you’re using — remember the same secret key. Next, a cryptographic algorithm is applied to generate a unique code based on this key and a counter value. A counter is essentially a number that increments each time a new one-time code is generated. The data for calculating this code is the same on both sides, so if everything goes according to plan, the two codes will be identical. What remains is to compare them: should the code you entered match the server-generated one, the authentication is successful.

After each request for a generation session, the counter value changes so that the code is one-time and unique. An algorithm is used that rules out performing reverse calculations and extracting the secret key from this code. So even if someone intercepts the one-time code, they won’t be able to calculate the secret key, reproduce the authenticator, and generate their own new codes.

There are two main issues with HOTP. First, the counter values easily get out of sync. For example, if you request the authenticator to generate a code but don’t use it, the client-side authenticator changes the counter value, while on the service side it remains the same. As a result, the generated codes no longer match. Second, the code stays valid until the counter value changes — potentially giving an attacker time to use the intercepted code if they somehow manage to distract the victim.

OATH TOTP

In 2011, a new standard was unveiled — OATH TOTP (time-based one-time password), which uses the current time as a counter. The principle remains the same: a secret key known to both parties is used to calculate a one-time code with the same cryptographic algorithm. And because the counter is based on Unix time, the code automatically changes at regular intervals, regardless of whether or not it is used.

Any internet-connected device now knows the exact time, so there’s no need to worry about one-time codes being out of sync. And since the interval after which the code changes is set rather short (30 seconds by default), if a one-time code is intercepted, the attacker won’t have much time to use it.

Basic principles of authenticators

These two standards are used by authenticator apps. TOTP is the more common of course, simply because it’s better in every way, but HOTP can still be found in some prehistoric implementations.

When creating an authenticator, the client and the server must set a common standard and share the key — this is the absolute minimum required for the authenticator app to work. Additional parameters can also be set for creating tokens. How do the app and the service come to an arrangement? In most cases, by means of a QR code. And this leads us to the next question: how does these codes work?

Authenticator QR code content

As far as I know, this is not among the standards developed by OATH, but rather a voluntary adherence to the format set by Google Authenticator. But either way, app-based authentication systems tend to use QR codes, in which a link (strictly speaking, a Uniform Resource Identifier, or URI) containing all the necessary information is encoded. Here’s an example of what it looks like:

otpauth://totp/Google:alanna@gmail.com?secret=IN2XE2LPOVZSYIDBOJSW4J3UEB4W65J7&issuer=Google&algorithm=SHA1&digits=6&period=30

As you can see, a whole bunch of parameters are transferred in the QR code, indicating the following:

• The purpose of the URI — creation of an authentication token (that’s what otpauth at the beginning is for)
• The authenticator standard, HOTP or TOTP; in this case, TOTP
• The token label to be displayed inside the app — in our example, Google
• The username — in this case, alanna@gmail.com
• The secret key from which the codes are generated (in Base32 format) — the most important part, a long string of random characters
• The name of the service that created the URI — in our example, Google again
• The algorithm used to generate the codes — in this case, SHA1
• The length of generated codes — usually six characters as shown here, but other variants are acceptable
• The period of time after which the code expires — usually 30 seconds, but other intervals can be set.

QR codes can pass a whole bunch of authentication token parameters

In fact, as we mentioned above, many of these parameters can be omitted. The token label and the username can be arbitrary, while the name of the service isn’t required at all — this information has no impact on code generation, and is there mainly for convenience. Some other parameters also aren’t mandatory. The authenticator uses the default code generation algorithm (SHA1) and produces a six-digit code with a 30-second update period unless encoded otherwise in the URI.

Essentially, the service and the authenticator only need to set the standard (HOTP or TOTP) and share the secret key. Thus, the following URI and QR code would yield exactly the same authentication token in functional terms as the previous pair:

Many QR code parameters can be omitted or set to arbitrary values; the main thing is to share the secret key and set a standard (HOTP or TOTP)

The bottom line is that most services that use app-generated codes for authentication operate with such QR codes. Any authenticator app, in turn, has support for reading such QR codes and converting them into authentication tokens, which, in turn, generate the one-time codes. So, instead of Google Authenticator, you can choose any of the dozens of alternatives that take your fancy.

A few exceptions: services that are incompatible with regular authenticators

For some reason that’s beyond me, not everyone in the IT industry follows the above standards: some prefer to come up their own. Here are some companies whose services and programs are not compatible with third-party authenticator apps (including Google Authenticator).

• Apple. The guys at Cupertino have their own 2FA system, which uses no third-party apps at all. Instead, the one-time codes are generated by the operating system simultaneously on all devices linked to an Apple ID. That’s how they roll!
• Valve and Blizzard. For security on Steam and Battle.net, the developers offer 2FA of their own creation: Steam Guard (built into Steam apps for both Android and iOS) and Battle.net Authenticator, respectively. As far as I know, there’s only one third-party authenticator app that supports these systems: WinAuth.
• Microsoft. For Microsoft account authentication, you have to install Microsoft Authenticator. On the upside, there’s no need to enter any codes: just confirm login by tapping a button in the app. As a bonus, Microsoft Authenticator also generates standard authentication tokens, which makes it a solid alternative to Google Authenticator. Incidentally, you don’t need a Microsoft account to use it.
• Adobe. The graphics software developer offers its own app for 2FA — Adobe Account Access — which works with similar logic to Microsoft Authenticator: login to your Adobe account is authenticated by tapping a button, not sending a code. In theory, the app also supports the creation of tokens for authentication in third-party services. However, to get Adobe Account Access to work, you must first link the app to your Adobe account, which, based on App Store and Google Play reviews, isn’t advised.

So, do I have to use Google Authenticator?

Not necessarily. All services that work with Google Authenticator will let you set up two-factor authentication using any alternative app. What’s more, many of them have significant advantages over Google’s creation.

Incidentally, we have a post about the most interesting authenticators for each popular operating system — Android, iOS, Windows, and macOS. And finally, if you’ve read this text in its entirety, then something tells us you might be interested in andOTP if you’re on Android, and OTP auth if you’re on iOS.

Resource : https://www.kaspersky.com/blog/authenticator-apps-compatibility/47063/