← Back to Security Center
Technical Architecture

Authenticator Threat Models

Multi-factor authentication is not a silver bullet. Different authentication mechanisms present entirely different attack surfaces. This post explores how modern authenticators defend against—and succumb to—various attack vectors.

Technical Introduction

A threat model is a structured representation of all the information that affects the security of an application. When evaluating an authenticator, we must map out the data lifecycle—from generation, to storage, to deployment—and identify how an adversary might intercept or manipulate the credential at each stage.

Problem Framing

The fundamental problem with legacy MFA (like SMS codes or basic TOTP) is that they rely on user validation. If the system asks the user to manually verify the origin of a request, the system is vulnerable to social engineering. Furthermore, the storage location of the cryptographic seed dictates the severity of a compromise.

Architectural Explanation

Let's evaluate three common attack vectors against an authenticator's threat model:

  • Adversary-in-the-Middle (AiTM): An attacker proxies traffic between the user and the real service. If the user enters a TOTP code into the proxy, the attacker forwards it to the real service, hijacking the session. TOTP offers zero defense against real-time AiTM. Passkeys completely neutralize this threat via cryptographic origin binding.
  • Device Malware: If a host device is infected with advanced malware (e.g., banking trojans with accessibility service abuse on Android), the malware can read TOTP codes off the screen or intercept autofill requests. Authenticators mitigate this by demanding biometric verification before displaying codes, but a fully compromised OS sandbox ultimately compromises the authenticator.
  • Cloud Account Compromise: If an authenticator synchronizes seeds to a cloud account, a breach of that cloud account (via weak passwords, SIM swapping, or credential stuffing) grants the attacker the entire vault. Local-first authenticators neutralize this by removing the cloud vector entirely.

Real-World Risks

We are increasingly seeing "MFA Fatigue" or "Prompt Bombing" attacks. In these scenarios, an attacker triggers hundreds of push-notification approvals. The user, annoyed or confused, eventually taps "Approve".

Standard TOTP avoids prompt bombing because the user must proactively retrieve and enter the code. However, as attackers pivot from credential stuffing to AiTM phishing frameworks (like Evilginx), the reliance on TOTP is becoming a liability, accelerating the industry's shift toward hardware-bound FIDO2/Passkey standards.

Glossary Concepts

  • Adversary-in-the-Middle (AiTM): An attack where a malicious actor secretly relays and possibly alters the communications between two parties who believe they are directly communicating.
  • MFA Fatigue: A social engineering technique where attackers repeatedly push MFA approval requests to a user's device until the user accidentally or intentionally approves one.
  • OS Sandbox: A security mechanism separating running programs, dictating that an application cannot read the memory or data of another application without explicit permission.

Frequently Asked Questions

Is SMS 2FA secure?

SMS is widely considered the weakest form of MFA due to the prevalence of SIM-swapping attacks and the lack of encryption in the SS7 telecommunications protocol. App-based authenticators are significantly more secure.

What is the most secure form of authentication?

Currently, hardware-backed, origin-bound public key cryptography (like YubiKeys or device-bound passkeys) provides the strongest defense against remote, scalable attacks.