Phishing is often described as a bad email, but the email is only the lure. The real question is what the sign-in flow allows after the user clicks. If a person can be fooled into typing a password, entering a one-time code, approving a push notification, or pasting a session link in a place controlled by an attacker, the flow is phishable. The weakness is not that people are careless. The weakness is that the system accepts proof that can be copied, relayed, or reused away from the place where it was meant to be used.

Start with proof

Authentication is the act of proving that a user is who they claim to be. A system can ask for something the user knows, such as a password; something the user has, such as a phone or hardware security key; something the user is, such as a fingerprint; or some signal about the situation, such as the device or network being used.

A sign-in flow is the sequence that collects and checks that proof. The flow matters because proof is only useful if it reaches the right verifier in the right context. A password typed into a fake page is still a real password. A one-time code read from a real authenticator app can still be used by an attacker if the attacker submits it quickly enough.

A flow is phishable when a user can be deceived into giving an attacker a credential, code, token, approval, or link that the attacker can use to complete sign-in. The attacker may never know the user's long-term password. They only need enough usable proof at the right moment.

📌
Core idea. Phishability is a property of the whole sign-in path, not of a single screen or factor.

A flow is more than a login page

It is tempting to picture authentication as a box labeled login. In practice, it is a chain: the user starts somewhere, the browser follows redirects, the identity provider asks for proof, the application receives a result, and a session is created. Each handoff is an opportunity either to preserve meaning or to lose it.

Modern systems often use OAuth 2.0, an authorization framework for granting limited access, and OpenID Connect, an identity layer built on OAuth 2.0. These protocols can be used safely, but they do not make a user interface phishing-resistant by themselves. A protocol can say which messages should be sent, while a criminal can still persuade a user to send the right message from the wrong place.

The safest mental model is to trace what an attacker can observe, copy, and replay. If a secret or approval can cross from the real user to the attacker and still be accepted, the flow has a phishable part.

Sign-in is a chain from user to redirects to proof check to a created session. The Sign-In Chain User starts Redirects Proof checked Session made
Sign-in is a chain from user to redirects to proof check to a created session.

How a phishable flow is stolen

A common attack begins with a believable message: an invoice, a file share, a calendar notice, a security alert, or a request from a senior person. The link leads to a page that looks like the normal sign-in page. The attacker may proxy the real site in real time, so the page behaves convincingly and the user sees familiar prompts.

The user enters a password. If the system asks for multi-factor authentication, often shortened to MFA, the fake site asks for that too. The attacker immediately relays the password and MFA response to the real service. If the proof is accepted, the real service creates a session. The attacker may capture the resulting session cookie, which is a small browser value that keeps a user signed in after login.

The user may think the attempt failed, or may be passed through to the real application and notice nothing. The important point is that the user did not merely disclose information. The user participated in building the attacker's session.

⚠️
The relay problem. If valid proof can be carried through an attacker-controlled page, training alone cannot make the flow safe.

The ingredients that make a flow phishable

Most phishable flows share a few design traits. They rely on proof that is portable, meaning it can be typed, read aloud, copied, forwarded, screenshotted, approved without context, or reused outside the original place where the user intended to sign in.

Passwords are the simplest example because they are shared secrets. Both the user and the service know the password, and anyone else who learns it can try it. One-time passwords reduce the time window, but they are still portable during that window. Push approvals avoid typing a code, but they can still be phishable if the user is asked to approve a sign-in they did not start or cannot recognize.

Session tokens also matter. A token is a digital bearer proof: whoever holds it can often act as the signed-in user until it expires or is revoked. Stealing a token can bypass the need to know the password or pass MFA again.

Phishable flows rely on proof that can be copied: passwords, one-time codes, and session tokens. Portable Proof Portable proofcan be copied Passwordsshared secret One-time codesshort window Session tokensbearer proof
Phishable flows rely on proof that can be copied: passwords, one-time codes, and session tokens.

Why some MFA is still phishable

MFA means the user must provide more than one kind of proof. It is a valuable control because it can stop many attacks that use only a stolen password. But MFA is not one thing. Different factors have different security properties, and some can still be relayed.

Text message codes are vulnerable because the code can be typed into a fake page and used immediately. Authenticator app codes are better in many ways, but the code is still a portable number. Push notifications can be strong when they show clear transaction details and require a deliberate match; they can be weak when they train users to tap approve to make a nuisance stop.

This is why the phrase phishing-resistant MFA matters. It does not mean the user can never be tricked. It means the authentication proof is bound to the real service and cannot be successfully replayed to a different origin, which is the scheme, host, and port of a web address.

  • A text message code can be copied into a fake page.
  • An authenticator app code can be relayed before it expires.
  • A vague push approval can be accepted without the user understanding the request.
  • A stolen session token can let an attacker skip the login ceremony entirely.
Text codes are relayable, push depends on context, and passkeys are bound to the real site. MFA by Strength SMS codesrelayable Push approvalscontext matters Passkeysorigin-bound weaker phishing-resistant
Text codes are relayable, push depends on context, and passkeys are bound to the real site.

What phishing-resistant flows change

A phishing-resistant flow changes the nature of the proof. Instead of asking the user to reveal a secret, it asks a device to prove possession of a private key without exposing that key. A private key is a secret value kept on the user's device or security key. A public key is the matching value registered with the service and safe to store there.

Passkeys are a common example. A passkey uses public key cryptography, where the service sends a challenge and the user's authenticator signs it. The signature is valid only for the registered service origin. If the user is on a fake site, the authenticator will not produce a signature for the real site, because the origin does not match.

Fast Identity Online 2, usually called FIDO2, and Web Authentication, usually called WebAuthn, are standards that support this pattern on the web. Their strength is not magic hardware or a prettier prompt. Their strength is cryptographic binding: the proof is made for one relying party and cannot simply be moved to another.

✅
Design shift. The best flows do not ask users to detect every fake; they make stolen proof unusable.
Phishable proof asks the user to reveal a secret; phishing-resistant proof proves a private key. Proof That Changes Phishablereveal a secret Phishing-resistantprove a key User can be tricked Key stays on device Can be relayed Bound to origin
Phishable proof asks the user to reveal a secret; phishing-resistant proof proves a private key.

Decisions leaders and practitioners actually face

The practical question is rarely whether phishing is bad. The question is where to spend effort first. A good program starts by finding the accounts and workflows where a stolen session would hurt most: administrators, finance staff, developers, help desk operators, executives, and systems that can change identity settings.

Leaders must decide how fast to move from phishable MFA to phishing-resistant MFA, how to handle people without compatible devices, how to recover accounts safely, and how to measure progress. Practitioners must decide which applications can enforce stronger flows, which legacy systems need compensating controls, and how to avoid creating fallback paths that undo the main protection.

A common mistake is to secure the front door and leave the side doors unchanged. Password reset, device enrollment, new phone setup, help desk verification, break-glass administrator accounts, and third-party access can all reintroduce phishable proof. The flow is only as resistant as the easiest path that reaches the same privilege.

  • Prioritize high-impact accounts before broad convenience accounts.
  • Remove or tightly govern fallback methods that use copyable codes or shared secrets.
  • Treat account recovery as part of authentication, not as an exception to it.
  • Measure adoption by protected access paths, not only by enrolled users.
  • Test real applications, because protocol support does not guarantee a safe user journey.

How to evaluate any sign-in flow

To evaluate a flow, ignore the branding and ask what the attacker would need. Can the user be tricked into typing it? Can the attacker relay it in real time? Can a token be stolen after sign-in? Can the same access be obtained through reset, enrollment, or support? These questions reveal the security property more clearly than the label on the login button.

Also ask what the user sees at the moment of decision. If the user is asked to approve something, does the prompt show the service, device, location, amount, or action in a way the user can understand? If the flow depends on the user noticing a strange domain name, assume it will fail sometimes. Human attention is not a cryptographic control.

The goal is not to eliminate every possible social attack. The goal is to make deception insufficient. A flow becomes much safer when a fooled user cannot export usable proof, when a stolen token has a short and narrow life, and when sensitive changes require fresh, strongly bound authentication.

⚠️
Watch the fallback. A phishing-resistant primary login can be defeated by a phishable recovery or enrollment path.

Key takeaways

  • A phishable flow lets a tricked user give an attacker proof that can be copied, relayed, reused, or turned into a session.
  • Multi-factor authentication helps, but codes and vague push approvals can still be phished in real time.
  • Phishing-resistant flows bind proof to the real service, so a fake site cannot reuse it successfully.
  • Passkeys, FIDO2, and WebAuthn use public key cryptography to avoid revealing a reusable secret during sign-in.
  • Recovery, device enrollment, help desk processes, and legacy fallbacks must be evaluated as part of the same flow.
  • The strongest designs reduce dependence on users spotting fakes and make stolen proof unusable.

Glossary

Authentication
The process of proving that a user, device, or service is who it claims to be.
Phishable flow
A sign-in or recovery path where a deceived user can provide proof that an attacker can use to gain access.
Multi-factor authentication
An authentication method that requires more than one kind of proof, such as a password plus a device approval.
Session token
A digital value that lets a service remember an authenticated session without asking the user to sign in again on every request.
Origin
The scheme, host, and port of a web address that define the security boundary a browser uses for many web protections.
Passkey
A passwordless credential that uses public key cryptography to sign in without revealing a reusable secret.
FIDO2
A set of open standards for phishing-resistant authentication using public key cryptography and authenticators such as phones or security keys.
WebAuthn
A web standard that lets sites use public key credentials, such as passkeys, for strong authentication in browsers and applications.