Google Authenticator stays central as MFA leans on TOTP

Google Authenticator stays central as MFA leans on TOTP

Google Authenticator continues to be the default time‑based one‑time password (TOTP) app for millions of users, even as the broader MFA ecosystem expands. The app’s ubiquity matters because most online services still rely on a shared secret and a six‑digit code generated on a phone.

Engadget’s recent guide walks users through moving the app to a new device without losing their codes, underscoring how often the migration step trips up non‑technical users. The same guide notes that the process is straightforward if the user retains the original QR code or secret key, a reminder that the underlying secret never changes during a device swap.

The algorithm behind the code

The HN post that broke down Google Authenticator’s internals explains that the app implements the TOTP algorithm. The algorithm combines a secret – a string such as the example $3cr3tP4$$ – with the current Unix time, then hashes the result with SHA‑1. The hash is truncated to produce a short numeric token that changes every 30 seconds.

Because the hash function is deterministic, the same secret always yields the same hash for a given time slice. The post warns that a naïve design that simply displayed the secret would let an attacker copy it and bypass the second factor entirely. By hashing and truncating, the app proves that the phone is present at the moment of authentication without ever revealing the secret itself.

Why static passwords fail as a second factor

The HN author illustrates a flawed approach: the server asks the user to type the exact password the app shows, such as $3cr3tP4$$. If the user can write that down, the phone becomes unnecessary, turning the second factor into a static password extension. This scenario highlights why time‑varying codes are essential – the token must change faster than an attacker can capture and reuse it.

The post also mentions that SHA‑1 is the hash function used by Google Authenticator and compatible apps. While SHA‑1 is considered weak for collision resistance, its use here is acceptable because the hash output is not exposed; only the truncated numeric token is transmitted.

Developers now embed TOTP directly

A separate HN discussion points out that the Verify API has added native TOTP support. The announcement encourages developers to adopt the same algorithm that powers Google Authenticator, reducing the need for third‑party libraries. The post includes a simple Flask example that starts with a username‑password check and then adds a TOTP verification step.

The code shows how a server can generate a QR code containing the shared secret, let the user scan it with Google Authenticator, and then validate the six‑digit code on login. By handling both the secret provisioning and the time‑based verification, developers can offer a seamless MFA experience without relying on SMS, which the same source calls less flexible.

The broader MFA landscape

While Google Authenticator remains popular, the HN author notes that FIDO2 hardware keys are “much more convenient” for many users. Yet the discussion also acknowledges that hardware tokens are not yet universal, especially on platforms where a phone is always at hand. Consequently, TOTP apps continue to fill the gap between strong password policies and full‑blown public‑key authentication.

The conversation about password‑only security echoes a longer trend: strong passwords alone no longer suffice against credential‑stuffing attacks, phishing, or malware. Adding a time‑based second factor raises the cost for attackers, because they must now compromise both the password and the device that holds the secret.

What to watch

The next wave of MFA will likely involve tighter integration of hardware‑based keys and tighter verification of the TOTP secret lifecycle. Watch for updates to the Verify API that may introduce stricter secret rotation policies or support for alternative hash functions. Also monitor whether Google Authenticator or its open‑source clones add support for newer algorithms, such as SHA‑256, which could address the lingering concerns around SHA‑1.