Multi-Factor Authentication, Passwords and Passkeys

If you remember only one statistic from this post, make it this one: year after year, the Verizon Data Breach Investigations Report finds that stolen or guessed credentials are involved in a plurality of breaches — typically somewhere between a third and a half, depending on the edition and how you count. Not zero-day exploits. Not elite nation-state tooling. Someone's password. Multi-factor authentication is the fix everyone has heard of; this post is about doing it in a way attackers can't route around.

Authentication is the process of proving you are who you claim to be, and multi-factor authentication (MFA) is how you stop a single stolen password from being enough. It sits at the front of every system, it's the control users interact with most, and it's the one we've historically done worst. The good news is that the last few years have produced real improvements — and that a lot of the advice you grew up with is now officially wrong.

Part 4 of 10 · Foundations of Infosec. Previous: Risk Management. Next: Least Privilege & Zero Trust.

Key takeaways

Stolen or guessed credentials are involved in a third to a half of breaches — authentication is the highest-leverage control.
NIST reversed the old password rules: no forced rotation, no composition rules, long passphrases, breach blocklists, slow hashing.
Multi-factor authentication ranges from weak (SMS) to phishing-resistant (FIDO2 keys, passkeys).
Passkeys remove the shared secret entirely — nothing to phish, guess or crack.

The three factors

Authentication evidence comes in three classic categories:

Something you know — a password, PIN or passphrase.
Something you have — a phone, a hardware key, a smart card.
Something you are — a fingerprint, face or other biometric.

Multi-factor authentication (MFA) means requiring evidence from more than one category. Two passwords is not MFA. A password plus a code from an app on your phone is. The point is that an attacker who steals one kind of evidence still lacks the other.

Passwords: the advice changed, and most people didn't notice

For twenty years, the rules were: change your password every ninety days, use a mix of upper, lower, digits and symbols, and never write it down. Those rules were codified by NIST in 2003 and copied into countless corporate policies.

In 2017, NIST reversed nearly all of them in Special Publication 800-63B, and the author of the original 2003 guidance, Bill Burr, publicly said he regretted it. The current guidance, reinforced in the 2024 revision, is:

Do not require periodic password changes. Forced rotation leads to predictable patterns (Summer2025! becomes Autumn2025!) and passwords written on sticky notes. Change a password when there's evidence it's compromised, not on a calendar.
Do not require composition rules. Mandating symbols and digits produces "P@ssw0rd", which every cracking tool tries first. Length matters far more than character classes.
Allow long passwords — at least 64 characters — and all printable characters including spaces, so people can use passphrases.
Check new passwords against a blocklist of known-breached and common passwords, and reject those. This single control does more than every composition rule combined.
Use a slow, salted hash to store passwords — bcrypt, scrypt or Argon2 — never plain SHA-256 and certainly never plaintext.
Rate-limit login attempts so online guessing is impractical.

The reasoning is grounded in how passwords are actually attacked. Almost nobody sits at your login page guessing. Attackers take a leaked database, crack the weakly hashed passwords offline at billions of guesses per second, and then try the results everywhere else — credential stuffing — because people reuse passwords. The defences that matter are therefore: unique passwords (so a leak elsewhere doesn't affect you), long passwords (so offline cracking is infeasible), and slow hashing (so a leak of your database yields few cracked passwords).

The only realistic way for a human to have unique, long passwords for two hundred services is a password manager. I recommend one to every client without exception. The objection — "what if the manager gets breached?" — is fair and has an honest answer: a well-designed manager stores an encrypted vault that even the vendor can't open, and even in the worst case you're better off with one strong master password than with one weak password reused everywhere.

Multi-factor authentication: not one thing

"Turn on MFA" is the single most effective piece of security advice available, and it's also incomplete, because the different kinds of second factor vary enormously in strength.

SMS codes. Better than nothing, and materially worse than everything else. Phone numbers can be hijacked by SIM swapping — persuading or bribing a carrier employee to move your number to the attacker's SIM — and SMS can be intercepted through weaknesses in the SS7 signalling network. NIST has discouraged SMS as an authenticator since 2017. Use it only when there is no alternative.

Authenticator apps (TOTP). The six-digit codes from Google Authenticator, Authy, Microsoft Authenticator and others. The code is generated from a shared secret and the time, so there's nothing to intercept over the network. Solid, widely supported, and the sensible baseline for most accounts.

Push notifications. "Approve this sign-in?" on your phone. Convenient, but vulnerable to MFA fatigue: the attacker, holding your password, triggers prompt after prompt until you tap Approve to make it stop. This is exactly how Uber was breached in 2022. Number matching — where the login screen shows a number you must type into the app — largely fixes this, and Microsoft now enforces it by default.

Phishing-resistant MFA. Here is the uncomfortable truth about all of the above: a code, a push or an SMS can be phished. Modern phishing kits (Evilginx is the best known) sit between you and the real site as a reverse proxy. You type your password and your code into what looks exactly like the genuine login page; the kit forwards them to the real site in real time and captures the resulting session cookie. Your MFA worked perfectly and you're still compromised.

The only authenticators that defeat this are ones cryptographically bound to the genuine website's origin: FIDO2 / WebAuthn security keys (YubiKey and similar) and passkeys. Because the authenticator signs a challenge that includes the site's domain, a proxy on a lookalike domain simply can't obtain a valid signature. CISA and NIST both now explicitly recommend phishing-resistant MFA for administrators and high-value accounts.

Passkeys: fixing the problem rather than patching it

Passkeys are the consumer-friendly form of FIDO2, backed by Apple, Google and Microsoft through the FIDO Alliance, and rolling out across major services since 2022.

Here's how they work, without the mathematics. When you register a passkey with a site, your device generates a key pair. The public key goes to the site; the private key stays on your device, protected by your fingerprint, face or PIN. To sign in, the site sends a random challenge; your device signs it with the private key after you unlock it; the site checks the signature against the public key it holds.

The consequences are profound:

There is no shared secret. The site stores only a public key, which is useless to an attacker. A breach of the site's database leaks nothing you can log in with.
Nothing to phish. The signature is bound to the site's origin. A fake site gets a signature that the real site will reject.
Nothing to remember or type. The user experience is "touch the sensor", which is why adoption is happening at all.

Passkeys can be synced across your devices through your platform's cloud keychain — convenient, and with a residual risk of being only as strong as your Apple or Google account — or held on a hardware key that never leaves your pocket. For most people, synced passkeys are a very large improvement over passwords; for administrators, a hardware key is worth the small inconvenience.

Are they perfect? No. Recovery — what happens when you lose every device — is still clumsy and varies by provider. Not every service supports them yet. But for the first time, the default authentication method for ordinary people is one an attacker can't phish, guess or crack. That's a genuine turning point.

Sessions: the part everyone forgets

Authentication happens once; then you get a session — a cookie or token that says "this browser is logged in". Attackers know this, which is why session hijacking is now a primary goal. Infostealer malware, which harvests browser cookies and sells them in bulk, has become one of the most common initial access methods observed by incident responders; a stolen session cookie walks straight past your password and your MFA.

Session hygiene therefore matters as much as login hygiene: short lifetimes for sensitive sessions, re-authentication for high-risk actions (changing an email address, making a payment), binding sessions to device characteristics where possible, and invalidating all sessions when a password changes. If you build software, this is your responsibility; if you buy it, it's a question to ask the vendor.

A practical policy

Pulling all this together, here's the authentication policy I hand to small and medium organisations. It fits on one page.

For everyone:

Use a company-provided password manager. Every account gets a unique, generated password.
MFA is mandatory on email, the identity provider, finance systems and anything that holds customer data. Authenticator app minimum; SMS only where nothing else exists.
Passkeys are enabled wherever supported, and staff are shown how to use them.
No forced password rotation. Passwords are changed on suspicion of compromise.
New passwords are screened against a breach list.

For administrators and executives:

Phishing-resistant MFA (hardware key or device-bound passkey), with a backup key stored securely.
Separate admin accounts from daily-use accounts; admin rights are never used for email or browsing.

For the organisation:

Single sign-on through one identity provider wherever possible, so there is one place to enforce policy and one place to cut access when someone leaves.
Offboarding disables the identity provider account the day the person leaves. Everything downstream follows.
Login anomalies — impossible travel, new-device sign-ins on admin accounts — generate alerts someone actually reads.

What this buys you

Google's own research found that adding a recovery phone number (i.e. even the weakest second factor) blocked 100% of automated bot attacks and the large majority of bulk phishing in their study. Microsoft has repeatedly stated that accounts with MFA are over 99% less likely to be compromised. Those are not marketing numbers; they reflect the fact that most attacks are automated and stop at the first real obstacle.

Authentication is where you get the most protection per hour of effort in all of security. Turn on MFA, deploy a password manager, move your admins to hardware keys, and fix offboarding. Do that, and you have closed the door that most attackers were planning to use.

Further reading

NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management (Rev. 3, 2017; Rev. 4 draft, 2024)
CISA, Implementing Phishing-Resistant MFA (2022)
FIDO Alliance, Passkeys — fidoalliance.org/passkeys
Google Security Blog, "New research: How effective is basic account hygiene at preventing hijacking" (2019)
Verizon, Data Breach Investigations Report (annual)
Troy Hunt, Have I Been Pwned — Pwned Passwords API (breach blocklist)

This series