Multi-Factor Authentication

Knowledge — something you know: a password, a PIN, an answer to a question. Copyable, phishable, reusable, and frequently already public.

Possession — something you have: a phone running an authenticator app, a hardware security key, a registered device with a stored private key. Requires the attacker to be in physical or logical control of a thing.

Inherence — something you are: a fingerprint or a face. In practice on modern devices this is not a factor sent to your server at all; it unlocks a private key held on the device, which means the factor your server sees is possession. That distinction matters when reasoning about what a compromise actually gives an attacker.

Two factors of the *same* type are not multi-factor. A password plus a security question is two pieces of knowledge, both copyable in the same breach, both phishable in the same form. The security benefit comes from the factors failing independently, so an attacker must run two different attacks with two different capabilities.

The reason TOTP and SMS are phishable is not implementation quality; it is that the user is asked to *transcribe a secret into a form*. A convincing fake login page collects the password and the code and relays both to the real site immediately. The code is valid for the attacker because nothing in the protocol ties it to the site the user believed they were on.

WebAuthn changes the structure. The authenticator signs a challenge together with the origin of the site requesting it, and the browser supplies that origin — the user cannot type it, mistype it, or be persuaded to substitute it. A signature produced for evil-app.example is simply not valid at app.example, so a relayed credential is useless. That is what "phishing-resistant" means: not that users are harder to fool, but that fooling them no longer produces anything the attacker can use. See Passkeys and WebAuthn.

This is why "we have MFA" is an incomplete statement in a security review. The follow-up question — *which factor, and is it phishing-resistant?* — separates a control that stops the dominant real attack from one that stops password reuse only. Both are worth having; they are not the same control.

Recovery codes are single-use secrets shown once at enrolment. They are a knowledge factor with the power of a possession factor, so they must be hashed at rest exactly like passwords, marked used atomically, and regenerable as a set. A recovery code stored in plaintext is an MFA bypass sitting in your database.

Recovery and support are where MFA is most often defeated without any technical attack. If a password reset does not require the second factor, MFA protects the login form and nothing else. If a support agent can disable MFA on a convincing phone call, MFA protects against remote attackers and not against social engineering — which is the branch a determined attacker will take, as Attack Trees makes visible.

Step-up decides how much a stolen session is worth. Even with MFA at login, a hijacked session can typically change the email address, add an API token, or disable MFA. Requiring the factor again for those specific operations is inexpensive and closes the most valuable post-compromise actions.

Enrolment is a boundary too: the moment a second factor is registered, whoever registered it controls the account going forward. Enrolment should require the current credential, notify the user, and — for high-value accounts — be blocked from a session that is itself new or unusual.