MFA and phishing-resistant authentication

What it means

An extra authentication prompt and protection against a lookalike website are not the same thing. The first concerns what evidence a login requires; the second concerns where that evidence can be used.

This comparison isolates that distinction. It keeps the user on a synthetic lookalike origin and changes only the authenticator type. The question is not whether either method makes an account invulnerable, but whether the impostor can obtain a response usable for the legitimate account.

Try it

Simulation: use only the synthetic choices. Do not submit real passwords, one-time codes, recovery codes, or private keys to a learning example. If an unexpected website requests them, stop the login attempt rather than testing whether a fresh code works.

Start with Authenticator type = typed OTP and User is on lookalike origin? = yes. Change Authenticator type to origin-bound passkey, inspect the result and its explanation, then select Compare with baseline to view the two outcomes. Reset returns to the starting inputs and clears errors and the comparison.

The initial example remains readable without JavaScript. The interactive controls require JavaScript; they do not contact a service or perform a login.

Typed credential can be phished. The typed code can be relayed by an attacker; MFA alone does not remove phishing risk.

Keep User is on lookalike origin? = yes. Only Authenticator type changes; correct relying-party and origin validation remain fixed assumptions.

Reset restores Authenticator type = typed OTP and User is on lookalike origin? = yes, removes input errors, and clears the baseline comparison. There is no running clock or stored event history to reset. Your independently opened or closed FAQ answers and About this model panel stay as you left them.

How it works

A phishing proxy succeeds along this path when the user supplies an authentication response to an impostor and the impostor can relay that response to the legitimate service. With a typed OTP, the response is a code the user can enter into either site. If it is relayed while valid, the legitimate service can receive an acceptable code even though the user supplied it on the wrong website. Adding another factor does not, by itself, fix that missing destination binding.

An origin-bound passkey changes the condition that makes the relay useful. Here, the relying party is the service requesting authentication, and the origin identifies the website context making the request. With correct relying-party and origin validation, the legitimate account’s credential is not usable for the simulated lookalike origin. The intermediate difference is therefore not “a harder code to guess”; it is that the wrong website cannot use the legitimate service’s credential under the stated binding rules.

These properties answer different questions. Factor requirements concern what authentication evidence the user must supply. Phishing-resistant binding concerns whether an impostor can obtain a usable authentication response through a lookalike site. Neither property alone establishes the security of the resulting session or recovery process.

WebAuthn also distinguishes user presence from user verification. Presence can be a touch confirming an authentication gesture; it is not necessarily a check of who is using the authenticator. Verification can involve a local PIN or biometric check. Whether a ceremony qualifies as MFA depends on the required and actually performed mechanisms, not the passkey label or touch alone. The simulation does not inspect those flags or run a WebAuthn ceremony.

Worked example

This is a synthetic baseline, not a captured login or observed attack.

The result is Typed credential can be phished. The typed code can be relayed by an attacker; MFA alone does not remove phishing risk.

The modeled opportunity is relay during the code’s validity window, not reuse after expiration. The wrong site can collect a manually entered response without that response establishing the intended destination. “Can be phished” describes this available attack path; it does not report that an attacker actually obtained a code or took over an account.

What changes when the condition changes

Change Authenticator type to origin-bound passkey. Keep User is on lookalike origin? = yes.

The result becomes Origin mismatch can block credential use. With correct relying-party and origin validation, the legitimate site’s credential is not usable for the lookalike origin. A separate credential for another relying party would not authenticate the legitimate account.

The attack condition has not disappeared: the user is still on the lookalike origin. What changes is whether the authentication mechanism lets that site obtain a response usable for the legitimate account. This is a difference in binding, not evidence that the user recognized the impostor.

In practice

For a service you own or are authorized to assess, begin with a read-only review of its authentication documentation and configuration you have permission to view. Keep the scope to that service’s login, session, and recovery paths; this page is not an enrollment or migration procedure.

Record separate findings:

• Factors: Which distinct factor types does the login actually require? A count of prompts is not enough.
• Binding: What documents the accepted relying party and origins, and what evidence establishes that validation is enforced?
• User verification: What verification does the service require, and what evidence shows that requirement is met?
• Remaining paths: How are authenticated sessions and lost-authenticator recovery handled?

The useful observation is a documented requirement with evidence of enforcement—not merely a setting or product label that says “MFA” or “passkey.” If evidence is missing, mark that property as unestablished. Stop the review if access rights are unclear; do not obtain broader access or collect another person’s credentials to fill the gap.

Do not change enrollment, recovery, or production authentication settings on the strength of this simulation. Any such change needs service-specific instructions, authorized scope, verification, and a recovery or rollback plan that this example does not supply.

Limits and unknowns

This is a qualitative comparison of one phishing path, not an account-security score or a prediction of attack success. Correct relying-party and origin validation are assumed. There is no control for broken validation, so the model cannot tell you whether a real deployment enforces it.

An origin-bound passkey is not automatically an MFA ceremony: the required user verification and the authenticator’s actual behavior matter. Even correctly bound authentication leaves session theft and account-recovery design as separate concerns.

If you set User is on lookalike origin? to no, either authenticator produces No lookalike origin in this exercise, with the explanation Both methods still require safe session and recovery controls. That branch removes this exercise’s attack condition; it does not establish that the methods are equivalent against other attacks.

Only the listed input choices are supported. If an invalid input state is reported, no calculated outcome applies until you correct it or use Reset. Uncertainty about a real service is different: the local model cannot resolve it, and a synthetic result must not be substituted for missing implementation evidence.

What to carry forward

For a lookalike-site threat, look for evidence of enforced relying-party and origin binding—not merely another authentication prompt. Assess factor requirements and user verification separately. If the service’s implementation is undocumented or its enforcement is uncertain, record phishing resistance as unestablished rather than inferring protection from a feature name.