Passkeys beat passwords because there’s no shared secret to steal: the website stores only a public key, and your device proves who you are by signing a challenge with a private key that is never sent to the website. Passwords, even strong ones, can be phished, reused and leaked from a breached database. Multi-factor authentication (MFA) closes some of those gaps, but not all MFA is equal, and knowing which kinds fail and why is basic knowledge for anyone starting in security.
This guide explains how each method works under the hood, how attackers defeat the weaker ones, and what defenders and SOC analysts look for. It’s written for career starters, so the focus is mechanism first, with personal tips at the end.
Authentication factors: the vocabulary
Every login method relies on one or more of three factor types:
| Factor | Also called | Examples |
|---|---|---|
| Something you know | Knowledge | Password, PIN |
| Something you have | Possession | Phone, hardware security key, SIM card |
| Something you are | Inherence | Fingerprint, face |
MFA means combining two or more different factor types. A password plus a security question is not MFA, because both are things you know. 2FA (two-factor authentication) is simply MFA with exactly two factors.
The US standard most security teams work from is NIST’s Digital Identity Guidelines, SP 800-63B-4, finalised in August 2025. It’s worth reading the sections on passwords and authenticator types; you’ll see them referenced in policy documents and audits.
Why passwords fail
A password is a shared secret: you know it, and the server stores something derived from it (ideally a salted, slow hash). That design has three structural weaknesses.
- It can be typed into the wrong place. A convincing fake login page collects it as easily as the real one. The user is the only line of defence, and people get tired, rushed and fooled.
- It gets reused. When one site is breached, attackers try the same email and password on other sites. This is called credential stuffing, and it works because people reuse passwords.
- It can be guessed. Short or common passwords fall to password spraying, where an attacker tries a few very common passwords against many accounts to stay under lockout thresholds.
What good password policy looks like now
SP 800-63B-4 changed a lot of the advice people grew up with. Among its requirements and recommendations:
- A minimum of 15 characters when the password is the only factor, or 8 characters when it’s used as part of MFA.
- Allow at least 64 characters, so passphrases work.
- No composition rules (no forced “one uppercase, one symbol”); they push people toward predictable patterns like
Password1!. - No forced periodic changes. Change passwords when there’s evidence of compromise, not every 90 days.
- Check new passwords against a blocklist of common, expected and known-compromised values.
- Allow password managers and autofill, including pasting.
- No password hints or security questions.
If you’re asked in an interview why forced rotation is discouraged, the answer is that it produces weaker, predictable passwords (Summer2026! becomes Autumn2026!) without stopping an attacker who already has the current one.
MFA types, from weakest to strongest
Not all second factors resist the same attacks. Here’s the practical ranking.
| Method | How it works | Main weakness | Phishing-resistant? |
|---|---|---|---|
| SMS or voice one-time code | Server sends a code to your phone number | SIM swap, number porting, phishing relay | No |
| Authenticator app code (TOTP) | App and server share a secret; both compute a code from the current time | Can be phished and relayed in real time | No |
| Push notification | Server sends “Is this you?” to an app | Push fatigue (repeated prompts until someone taps Approve) | No |
| Push with number matching | You type a number shown on the login screen into the app | Still relayable through a live phishing proxy | No |
| Passkey or FIDO2 security key | Device signs a challenge bound to the real website’s domain | Account recovery and device loss become the weak points | Yes |
SMS codes and SIM swap
SMS one-time passwords tie your account to a phone number, and a phone number is controlled by a mobile network, not by you. In a SIM swap, an attacker persuades or bribes someone at a mobile network to move your number to a SIM they hold, then receives your codes. Porting your number to another network has the same effect.
NIST classifies SMS and voice codes as a restricted authenticator in SP 800-63B-4. They can still be used, but organisations that do must assess the risk, offer an alternative, and should watch for warning signs such as a recent SIM change or number port before trusting a code.
SMS 2FA is still far better than a password alone. It’s just not where you want to stop for email, banking or admin accounts.
Push fatigue
Push-based MFA is convenient: a prompt appears and you tap Approve. Once an attacker has a valid password, they can trigger prompt after prompt, often late at night, until the user taps Approve to make it stop. This is called push fatigue or MFA bombing.
Number matching (typing a code from the login screen into the app) defeats blind approvals, because a person who isn’t logging in has no number to type.
Why codes can be phished
Any factor where a human reads something and types it somewhere can be phished. With an adversary-in-the-middle (AitM) phishing kit, the fake site sits between the victim and the real site: it passes the password and the one-time code through to the real site in real time, then keeps the session cookie the real site sends back. The attacker now has a logged-in session, and MFA was technically satisfied.
That’s why the industry is moving to phishing-resistant authentication.
How passkeys work
Passkeys are built on the FIDO2 standards from the FIDO Alliance: WebAuthn, a W3C standard that browsers and websites use, and CTAP (Client to Authenticator Protocol), which lets a browser talk to an authenticator such as a phone or a USB security key.
Registration
- You choose “Create a passkey” on a website.
- Your device (the authenticator) generates a new key pair just for that website: a private key and a public key.
- The private key stays on your device, protected by its secure hardware. If you use a synced passkey, it’s copied to your other devices through your platform’s end-to-end-encrypted sync.
- The device sends the public key to the website, which stores it against your account.
Sign-in
- The website sends a random challenge.
- Your browser tells the authenticator which website (the relying party) is asking. The authenticator only uses the key created for that exact domain.
- You confirm it’s you the same way you open your phone: fingerprint, face or PIN. That check happens locally; your biometric never leaves the device.
- The authenticator signs the challenge with the private key.
- The website checks the signature with the public key it stored. If it verifies, you’re in.
Why this defeats phishing
Three properties do the work:
- No shared secret. The server holds only a public key. A breach of the website’s database gives attackers nothing they can log in with.
- Origin binding. The key is tied to the real domain. A lookalike site such as
acme-bank-login.testcan’t ask for the signature foracme-bank.test, because the browser reports the real origin. The user can’t be tricked into handing it over, because there’s nothing to type. - Fresh challenges. Each signature covers a new random challenge, so a captured response can’t be replayed later.
SP 800-63B-4 defines phishing resistance in exactly these terms: the protocol itself prevents secrets from reaching an impostor, without relying on the user noticing anything. Cryptographic authenticators with channel or verifier-name binding, which is what FIDO2 provides, qualify. Codes you type in don’t.
Synced versus device-bound passkeys
| Type | Where the private key lives | Trade-off |
|---|---|---|
| Synced passkey | Copied across your devices via an encrypted cloud keychain | Convenient and easy to recover; security depends on the sync account |
| Device-bound passkey | Stays on one device, such as a hardware security key | Highest assurance; lose the device and you need a backup method |
NIST allows syncable passkeys up to its AAL2 assurance level. AAL3 requires that keys can’t be exported, which means device-bound authenticators.
Where passkeys still go wrong
Passkeys move the weak point to account recovery. If “Forgot your passkey?” falls back to an SMS code or a support agent who can be talked round, attackers aim there instead. Good implementations protect recovery as carefully as sign-in.
How defenders detect authentication attacks
This is where career starters earn their keep. In a SOC you’ll see these patterns in identity provider and sign-in logs:
| Attack | What it looks like in logs | Typical response |
|---|---|---|
| Password spraying | Many accounts, one or two failed attempts each, from the same source or a small set of IPs | Block the source, check for any successes, enforce MFA and blocklisted passwords |
| Credential stuffing | High volume of failures across many accounts, often with valid usernames from a known breach | Rate limiting, bot detection, force resets for accounts that succeeded |
| Push fatigue | Several MFA prompts denied or ignored, then one approved, often at an odd hour | Revoke sessions, reset the password, contact the user, enable number matching |
| AitM phishing | Successful MFA sign-in followed by session use from a different IP, country or device | Revoke tokens, reset credentials, look for new mailbox rules or added MFA methods |
| SIM swap | Customer reports loss of mobile service; SMS-based reset soon after | Freeze the account, check the network’s SIM-change signal, move to stronger MFA |
Two habits make you useful quickly. First, after any confirmed account compromise, check what the attacker changed: new MFA devices, email forwarding rules, recovery phone numbers. Attackers add persistence before you notice them. Second, read the alert’s sign-in details, not just its title. Location, device, user agent and authentication method tell the story.
For the full attack chain, read how account takeovers work and how defenders stop them. The UK’s NCSC guidance on multi-factor authentication is a clear, practical reference for organisations choosing MFA types.
What you can practise this week
You don’t need a lab budget to build real understanding:
- Watch WebAuthn work. Open your browser’s developer tools on a demo site that supports passkeys, register a passkey, and read the registration and sign-in requests. Find the challenge, the relying party ID and the signature.
- Audit your own accounts. For email, banking and social accounts, list which MFA method each uses. Upgrade where you can.
- Write a detection rule in plain English. For example: “Alert when one user denies three or more MFA push prompts within ten minutes and then approves one.” That’s the logic behind real SIEM rules.
- Review a password policy. Take any policy you can find (a school’s, a club’s, or a fictional company’s) and rewrite it to match SP 800-63B-4.
Protecting your own accounts
The personal checklist, in priority order:
- Use a password manager and a unique password for every site.
- Turn on passkeys wherever your important accounts offer them, starting with your email, because email resets everything else.
- Where passkeys aren’t offered, prefer an authenticator app or security key over SMS.
- Never approve an MFA prompt you didn’t start, and never read out a one-time code to anyone who calls you, whatever bank or company they say they’re from.
- Set up recovery options before you need them, and keep backup codes offline.
- Ask your mobile network about SIM-swap protection such as a port-out PIN, if it offers one.
WhatsApp and social media accounts have their own quirks; see our guides to WhatsApp account takeover and the social media defender’s checklist.