What is Multi-Factor Authentication (MFA)?

Multi-factor authentication is a login control requiring two or more different kinds of proof — something you know, have, or are. The word different is load-bearing and widely fumbled: a password plus a security question is two proofs from one category — knowledge — and therefore not MFA at all. The point is combinatorial: a phished password doesn’t hold your phone; a stolen phone doesn’t know your PIN; each factor’s theft leaves the attacker one category short.

Key takeaways

How TOTP actually works

The authenticator app, demystified — no ranking page explains the machinery (RFC 6238):

Enrollment   QR code = otpauth://totp/app:ada?secret=JBSWY3DP…
             → the app now shares a Base32 SECRET with the server

Every 30 s   both sides compute, independently and offline:
             code = truncate( HMAC-SHA1( secret, floor(unix_time / 30) ) ) % 10⁶

Login        you type the app's 6 digits; the server computes its own,
             accepts ±1 time window for clock drift → match = possession proven

Wiring that into an app’s login flow:

// JavaScript / Node.js — Back4app JS SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
await currentUser.save({
  authData: { mfa: { secret: totpSecret, token: codeFromApp } },
});
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
const user = await Parse.User.logIn('ada', password, {
  authData: { mfa: { token: codeFromApp } },
});

// Flutter / Dart — Back4app Flutter SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
currentUser.set('authData', {
  'mfa': {'secret': totpSecret, 'token': codeFromApp},
});
await currentUser.save();
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
final user = ParseUser('ada', password, null)
  ..set('authData', {'mfa': {'token': codeFromApp}});
await user.login();

// iOS / Swift — Back4app Swift SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
let enrolled = try await currentUser.link("mfa",
    authData: ["secret": totpSecret, "token": codeFromApp])
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
let user = try await User.login("ada", password: password,
    authData: ["mfa": ["token": codeFromApp]])

// Android / Kotlin — Back4app Android SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
val enroll = mapOf("secret" to totpSecret, "token" to codeFromApp)
ParseUser.getCurrentUser().linkWithInBackground("mfa", enroll)
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
val authData = mapOf("token" to codeFromApp)
ParseUser.logInWithInBackground("mfa", authData) // paired with the password check

MFA vs. 2FA

One table settles it; the sharper question is which factors — because the security ceiling is set not by how many proofs you stack but by whether any of them can be phished.

The method ranking, honestly

The comparison the CISA guidance publishes and vendor explainers won’t — which attacks defeat which methods:

The pattern in the leftmost column is the modern story: every code and approval can be relayed through a phishing proxy; only origin-bound cryptography survives contact with a fake login page.

The attacks, in plain language

Adversary-in-the-middle phishing: open-source proxy kits sit between victim and real site, relaying password and one-time code live, then keep the resulting session cookie — MFA “passed,” account lost. Push bombing: with a stolen password, spam approval prompts until fatigue wins one tap; number matching (type the digits shown on screen) removes the mindless-approve path. SIM swapping: persuade a carrier to move the victim’s number, then receive their SMS codes — the attack that put SMS at the bottom of the table. The common thread: these defeat factors that can be told to someone; they all break against factors that only speak cryptographically to the genuine origin.

The recovery problem

Every MFA rollout creates a second door: what happens when the phone is lost? Backup codes — single-use, generated at enrollment, stored offline — are the standard answer; account recovery flows are the dangerous one. If a help-desk call or an email reset can remove MFA, the attacker calls the help desk — the technique behind headline breaches — and your strongest control is overridden by your weakest process. The rule: recovery must demand assurance equal to or higher than the login it replaces — multiple enrolled methods, step-up verification for resets, and MFA removal treated as a privileged, logged, alert-raising event.

How effective is MFA, really?

Two true claims, often confused. Against automated attacks — credential stuffing, password spraying — MFA is near-total: the famous ninety-nine-percent figures come from large-scale sign-in telemetry measuring exactly those, and a peer-reviewed follow-up found ~99% compromise reduction in the same scope. Against targeted phishing with real-time proxies, code- and push-based MFA is demonstrably bypassable, which is why critics put all-attacks effectiveness far lower and why agencies now push phishing-resistant methods specifically. The honest synthesis: any MFA ends the era of the password being enough; only passkey-class MFA ends phishing. Deploy some MFA everywhere, and phishing-resistant MFA wherever the stakes justify the enrollment friction.

Common use cases

• Protecting account issuance — MFA guards the moment sessions and tokens are minted; everything downstream trusts that gate.
• Step-up for sensitive actions — re-prompt at payment, deletion, or key export, not just at login.
• Admin and privileged accounts — where MFA should be mandatory and phishing-resistant, no exceptions.
• Compliance regimes — payment, health, and government frameworks increasingly require MFA outright.
• Complementing social login — inherited from the identity provider, or enforced locally for high-value actions.

Which MFA method should you offer? A decision matrix

Limitations and trade-offs

• Friction is real and measurable. Every prompt costs conversion and support tickets; adaptive, risk-based prompting spends friction where risk lives.
• Phishable MFA buys less than it seems. Against a targeted proxy attack, codes and pushes fall; treat them as automation-stoppers, not phishing armor.
• The phone is a single point of failure. Device loss without recovery planning becomes lockout at scale — enrollment UX must plant backup methods on day one.
• Recovery flows invert the math. A weak reset path silently caps your whole scheme at its own strength.
• Enrollment is the adoption cliff. Mandates without smooth QR flows and clear fallbacks generate resistance; the best scheme is the one users actually complete.

MFA on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. TOTP arrives as configuration, not construction: Back4app’s mfa auth adapter turns on time-based codes with a config block — digits, period, and algorithm tunable — and the code tabs show the whole client story: enrollment proves possession by pairing the shared secret with one valid code, the server issues single-use recovery codes, and subsequent logins pair the password with the current six digits. Because the platform’s sessions are revocable server-side, the surrounding hygiene holds too: an MFA change can terminate other sessions immediately, and Cloud Code triggers are the natural place to log enrollment events and gate MFA removal behind step-up checks — the recovery discipline this article argues for, expressed in a few functions.