Prerequisite. This lesson continues directly from the [Two-Factor Authentication](/lessons/two-factor-authentication) lesson. If you have not completed it, finish it first — the concepts here assume you already know what TOTP and SMS one-time codes are and why a second factor matters.
The Two-Factor Authentication lesson made one point: a password alone is not enough, so we add a second factor — a TOTP code or an SMS message — so that a stolen or reused password cannot log an attacker in by itself. That is true and valuable. But it hides two things this lesson is about.
*First: not every second factor is a strong factor. SMS and TOTP codes are short secrets the user reads off a screen and types into whatever page asked for them. A convincing phishing site simply asks for the code in real time and relays it to the real site — the user hands the attacker a perfectly valid second factor without realising it. The codes are phishable*. WebAuthn / passkeys fix this at the root: the credential is a public/private key pair, the private key never leaves the user's device, and it is cryptographically bound to the real site's origin, so the browser will not release it on a fake site. There is no transferable secret to phish. That property — phishing resistance — is why the industry is moving to passkeys, and it is the first half of this lesson.
Second: in real engagements you rarely break the cryptography — you walk around it. The recurring wins are implementation flaws that recur no matter which factor is used:
- The second factor is requested by the page but not enforced server-side, so browsing straight to the post-login URL skips it entirely.
- The verification endpoint returns a client-trusted flag (
"verified": false) that you can simply flip. - The OTP is replayable or not rate-limited, so it can be reused or guessed.
- "Remember this device", backup codes, or account recovery are weaker than the primary factor — and an attacker just attacks the weak path (a downgrade).
Authorised targets only. Skipping past a 2FA prompt, replaying a code, or tampering a verification response is active testing of an authentication control. Do it only against the embedded NovaCart application here, a WebAuthn demo that invites experimentation, or your own authorised program. If unsure, revisit Hacking Ethics and Authorization.
By the end you will be able to explain why a passkey survives a phishing attack that beats SMS, and you will carry a concrete MFA-bypass checklist you can run against any second-factor implementation.