Episode 21 · Module 5 · Authentication

Multi-Factor Authentication

19 May 2026 · 8:46 · Security for Legal SaaS

8:46 8:46

In Episode 17, we examined how passwords are stored securely using hashing algorithms like bcrypt and Argon2id. But even a perfectly hashed password has a fundamental limitation: it is a single factor. If an attacker obtains a user's password — through phishing, credential stuffing, a breach of another service, or simple guesswork — they have everything they need to impersonate that user. Multi-factor authentication (MFA) addresses this by requiring evidence from two or more independent categories before granting access. Microsoft's analysis of account compromises found that MFA blocks 99.9% of automated attacks on accounts.

Today’s Lesson

Security for Legal SaaS — Episode 21: Multi-Factor Authentication

Why Passwords Alone Are Not Enough

Multi-factor authentication (MFA) addresses this by requiring evidence from two or more independent categories before granting access. Microsoft's analysis of account compromises found that MFA blocks 99.9% of automated attacks on accounts.¹ For legal SaaS platforms handling privileged client communications and case strategy, MFA is not optional — it is a baseline professional obligation.

The Three Factor Categories

Authentication factors fall into three categories:

Category	Description	Examples
Something you know	A secret the user has memorised	Password, PIN, security question
Something you have	A physical object the user possesses	Phone (for TOTP codes), hardware security key, smart card
Something you are	A biometric characteristic	Fingerprint, face scan, iris pattern

True MFA requires factors from at least two different categories. Two passwords are not MFA — they are two instances of the same factor category. A password (something you know) combined with a six-digit code from an authenticator app on your phone (something you have) qualifies because it draws from two independent categories.²

NIST SP 800-63B formalises this through Authenticator Assurance Levels (AALs). AAL1 permits single-factor authentication. AAL2 requires multi-factor authentication — at minimum, a password plus a second factor. AAL3 requires hardware-based cryptographic authenticators, such as FIDO2 security keys.³ Any system handling personally identifiable information must implement at least AAL2.

MFA Methods Compared

Not all second factors provide equal security. The table below ranks common methods from weakest to strongest:

Method	Factor Type	Phishing Resistant?	Strengths	Weaknesses
SMS codes	Something you have (phone number)	No	Easy to deploy, familiar to users	Vulnerable to SIM swapping, SS7 interception, real-time phishing relays
Email codes	Something you have (email account)	No	No app installation required	Depends on email security; phishable; delays in delivery
TOTP apps (Google Authenticator, Authy)	Something you have (device with shared secret)	No	Works offline, no SMS dependency	Codes can be phished in real time; shared secret can be extracted from compromised devices
Push notifications (Duo, Microsoft Authenticator)	Something you have (registered device)	Partial	Convenient; harder to phish than codes	Vulnerable to MFA fatigue attacks (repeated push spam)
Hardware security keys (YubiKey, Titan)	Something you have (physical key)	Yes	Cryptographically bound to domain; immune to phishing	Physical device required; cost per key; loss/replacement logistics
Passkeys / WebAuthn	Something you have + something you are	Yes	Phishing resistant; no shared secret; synced across devices	Ecosystem still maturing; platform lock-in concerns

Key stat: NIST SP 800-63B explicitly deprecates SMS as a standalone second factor due to demonstrated vulnerabilities in the telephone network, including SIM swap fraud and SS7 protocol exploitation.⁴

TOTP: The Current Workhorse

Time-Based One-Time Passwords — TOTP, defined in RFC 6238 — are the most widely deployed MFA method in legal SaaS today.⁵ During setup, the server generates a shared secret and displays it as a QR code. The user scans it with an authenticator app (Google Authenticator, Authy, 1Password). Every 30 seconds, both the server and the app independently compute a six-digit code from the shared secret combined with the current timestamp. At login, the user enters the current code to prove they possess the device holding the secret.

TOTP is a substantial improvement over passwords alone. It works offline, requires no SMS delivery infrastructure, and is free to implement. But it has limitations:

Phishable. An attacker who creates a convincing fake login page can capture both the password and the TOTP code in real time, then relay them to the real server before the code expires. This is called a real-time phishing proxy.⁶
Shared secret exposure. The TOTP seed is a symmetric secret — if the server's database of TOTP seeds is breached, every user's second factor is compromised simultaneously.
Backup code risk. Most implementations generate one-time backup codes at enrolment. These are often stored insecurely by users (screenshots, notes apps, email to self) and become a secondary attack vector.

Push Notifications and MFA Fatigue

Push-based MFA — where the user approves a login attempt by tapping "Approve" on their phone — improves usability over typing codes. But it introduced a new attack vector: MFA fatigue.

Case study: Uber, September 2022. An attacker purchased stolen credentials for an Uber contractor from a dark web marketplace. When MFA push notifications blocked the initial login, the attacker sent over 40 push notifications in 30 minutes to the contractor's phone, then contacted them via WhatsApp pretending to be Uber IT security, telling them to approve the notification to make it stop. The contractor complied. The attacker gained VPN access, found admin credentials in a PowerShell script, and escalated to full administrative control over Uber's cloud infrastructure.⁷

Mitigations for MFA fatigue include number matching (the user must type a number displayed on the login screen into the push notification, proving they can see both screens), location context (showing the geographic origin of the login attempt), and rate limiting push requests. Microsoft, Okta, and Duo have all added number matching as a default or recommended setting since the Uber incident.⁸

Passkeys and WebAuthn: The Phishing-Resistant Endgame

WebAuthn, the web standard developed by the W3C and the FIDO Alliance, uses public-key cryptography instead of shared secrets.⁹ During registration, the authenticator generates a unique key pair. The private key never leaves the device. The public key is sent to the server. During authentication, the server sends a challenge; the authenticator signs it with the private key, and the server verifies the signature against the stored public key.

Critically, WebAuthn binds the credential to the origin (the website's domain). The authenticator checks that the domain requesting authentication matches the domain where the credential was registered. A phishing site at `login-legalplatform.com` cannot trick the authenticator into signing a challenge for `legalplatform.com`. Phishing becomes cryptographically impossible — not just difficult, but mathematically excluded.¹⁰

Passkeys are the consumer-friendly evolution of WebAuthn. They sync the private key across devices using platform-specific vaults (iCloud Keychain, Google Password Manager, 1Password). This solves the hardware key's biggest usability problem — loss of a single device no longer means lockout. The tradeoff is that the security now depends on the platform account's protection (which should itself be MFA-protected).¹¹

Regulatory momentum: The U.S. Cybersecurity and Infrastructure Security Agency (CISA) explicitly recommends phishing-resistant MFA based on FIDO2/WebAuthn for all organisations, with special urgency for high-value targets — a category that includes law firms holding litigation strategy and M&A communications.¹²

Recovery Flows: The Weakest Link

The strongest MFA is only as good as its recovery process. If a user loses their second factor, how do they regain access?

Common recovery mechanisms and their risks:

Recovery Method	Risk
SMS-based recovery code	Defeats the purpose of hardware keys; vulnerable to SIM swap
Email-based recovery link	Security depends on email account protection
Pre-generated backup codes	Often stored insecurely by users
Admin manual override	Social engineering risk; requires identity verification procedure
Secondary hardware key	Strongest option; requires users to register two keys at enrolment

The OWASP Multi-Factor Authentication Cheat Sheet recommends treating factor replacement as a high-risk action requiring reauthentication with an existing enrolled factor, never relying solely on the active session.¹³ For legal SaaS platforms, the recommended approach is: require users to register at least two independent second factors at enrolment, and verify identity through an out-of-band process (phone call with identity verification, physical office visit) before resetting MFA for users who have lost all factors.

Breaches That MFA Would Have Prevented

Incident	Year	Root Cause	MFA Impact
Colonial Pipeline	2021	Compromised VPN password on dormant account with no MFA	Basic MFA on the VPN would have blocked the attack entirely¹⁴
Uber	2022	MFA fatigue — push notification spam	Phishing-resistant MFA (FIDO2) would have been immune to the social engineering⁷
Okta (Lapsus$)	2022	Compromised support contractor credentials	Hardware key requirement for privileged access would have prevented lateral movement
MGM Resorts	2023	Social engineering of help desk to reset MFA	Stronger identity verification in recovery flow would have blocked the reset¹⁵

Mandatory MFA for Legal SaaS: Professional Obligation

The ABA's 2023 Legal Technology Survey Report found that fewer than half of solo practitioners and small firms use MFA — despite ABA Model Rule 1.6(c) requiring "reasonable efforts" to prevent unauthorised access to client information.¹⁶ Cyber insurance underwriters have responded: as of 2025, most carriers require MFA on all accounts, 24/7 endpoint monitoring, and a written incident response plan as preconditions for coverage.

For legal SaaS vendors, the calculus is straightforward:

Enforce MFA for all users, not just admins. Provide TOTP as the baseline, passkeys as the recommended option.
Offer phishing-resistant MFA (WebAuthn/passkeys) for firms handling high-sensitivity matters — litigation strategy, M&A, government investigations.
Design recovery flows carefully. Never allow SMS-only recovery to bypass a hardware key enrolment. Require a second registered factor or an identity-verified admin override.
Log all MFA events — enrolment, successful verification, failed attempts, recovery — with immutable audit trails.

What's Next

Episode 22 covers Single Sign-On, SAML, and Enterprise Identity — how law firms centralise authentication across dozens of SaaS platforms and what security guarantees SSO actually provides (and which it does not).

Sources & Further Reading

Sources & references

OWASP, Multifactor Authentication Cheat Sheet (citing Microsoft analysis: MFA blocks 99.9% of automated account compromises).
OWASP, Authentication Cheat Sheet — Multi-Factor Authentication.
NIST, SP 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management, Sections 4.2 (AAL2) and 4.3 (AAL3).
NIST, SP 800-63B Section 5.1.3.3 — restricted status for SMS-based authenticators.
IETF, RFC 6238: TOTP: Time-Based One-Time Password Algorithm.
Evilginx / real-time phishing proxy — documented in OWASP Testing Guide, Testing Multi-Factor Authentication.
UpGuard, What Caused the Uber Data Breach in 2022?.
Microsoft, Number matching in multifactor authentication; Duo and Okta adopted similar defaults post-2022.
W3C, Web Authentication: An API for accessing Public Key Credentials.
Token2, Why FIDO2 Is More Secure Than TOTP.
FIDO Alliance, Passkeys — FIDO Alliance Specifications.
CISA / IDManagement.gov, Phishing-Resistant Authenticator Playbook.
OWASP, Multifactor Authentication Cheat Sheet — Factor Update Security.
Wikipedia, Colonial Pipeline Ransomware Attack — VPN account with no MFA enabled.
BleepingComputer, MGM Resorts Shuts Down IT Systems After Cyberattack (September 2023).
ABA, 2023 Legal Technology Survey Report — MFA adoption rates across firm sizes.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. So Episode 21 — multi-factor authentication, or MFA. Alice, we spent the last few episodes on passwords, sessions, tokens, and OAuth. This feels like the natural next step — what happens when a password isn't enough?

Alice: Exactly. And the short answer is: a password is never enough on its own. We talked in Episode 17 about how passwords are stored using hashing, and in Episode 14 we covered credential stuffing — attackers taking leaked passwords from one breach and trying them everywhere else. MFA exists because no matter how well you store a password, you can't control whether the user reuses it on a site that gets breached tomorrow. So you add a second lock to the door.

Dan: Right. So what counts as a "factor" here?

Alice: There are three categories. Something you know — that's your password or a PIN. Something you have — a physical object, like your phone or a hardware key. And something you are — a biometric, like your fingerprint or face scan. True MFA means combining factors from at least two different categories. Two passwords is not MFA. A password plus a code from an app on your phone — that qualifies, because the password is something you know and the phone is something you have.

Dan: Mm. That makes sense. So what are the common ways people implement that second factor?

Alice: The most common today is TOTP — time-based one-time passwords. Those six-digit codes that change every thirty seconds, from apps like Google Authenticator or Authy. When you set it up, the server creates a shared secret and shows you a QR code. You scan it with the app. From then on, both the server and your app independently calculate the same code from the secret plus the current time. At login, you type the code to prove you have the device with the secret on it.

Dan: And that's pretty solid, right?

Alice: <sigh> It's better than nothing — far better. But it has a real weakness. The code can be phished. Imagine an attacker sets up a fake login page that looks exactly like your legal SaaS platform. You type your password and your six-digit code. The attacker's server captures both in real time and immediately submits them to the real server. The code is valid for thirty seconds — plenty of time for an automated relay. So TOTP protects you against someone who stole your password from a database dump. It does not protect you against a sophisticated phishing page that intercepts your login in real time.

Dan: Hmm. That's a bit unsettling. What about those push notifications — where your phone buzzes and you just tap Approve?

Alice: Push-based MFA, like you'd see with Duo or Microsoft Authenticator. It's more convenient than typing codes, and it's slightly harder to phish because there's no code to intercept. But it introduced a new kind of attack called MFA fatigue. The Uber breach in September 2022 is the textbook case. An attacker bought stolen credentials for an Uber contractor from the dark web. The account had push MFA, so the attacker couldn't just log in. Instead, they sent over forty push notifications to the contractor's phone in thirty minutes. Then they messaged the contractor on WhatsApp pretending to be Uber IT, saying "approve the notification to make it stop." The contractor did. The attacker was in.

Dan: Mm. Forty notifications. That's social engineering on top of a technical attack.

Alice: Exactly. And it worked. Once inside, the attacker found admin credentials in a script file and escalated to full control of Uber's cloud systems. Since then, vendors have added number matching — where the login screen shows a two-digit number and you have to type it into the push notification on your phone, proving you can see both screens. That blocks the fatigue attack because you can't just tap blindly.

Dan: Right. So where do hardware keys and passkeys fit in? I keep hearing passkeys are the future.

Alice: They are. Hardware security keys — like a YubiKey — and passkeys both use a standard called WebAuthn, developed by the W3C and the FIDO Alliance. Here's the key difference from TOTP: there's no shared secret. When you register the key, it creates a unique pair of cryptographic keys. The private key stays on your device and never leaves. The public key goes to the server. When you log in, the server sends a challenge, your key signs it, and the server checks the signature. No code to type. No code to intercept.

Dan: Yeah, but what stops a phishing site from using that same process?

Alice: This is the clever part. The key checks the website's domain before signing anything. If you're on the real site — legalplatform.com — the key signs the challenge. If you're on a fake site — login-legalplatform.com — the key refuses because the domain doesn't match what was registered. It's not just harder to phish. It's cryptographically impossible. The maths won't work on the wrong domain.

Dan: Mm-hmm. That's a meaningful difference. But hardware keys — people lose them. What happens then?

Alice: That's exactly where recovery flows come in, and honestly, recovery is the weakest link in any MFA system. If your recovery mechanism is "we'll send you an SMS code," then an attacker who can SIM-swap your phone number can bypass your hardware key. You've installed a vault door and left the window open. The best practice is to register two independent second factors at setup. Two hardware keys stored in different locations, or a hardware key and a passkey synced to your platform account. If both are lost, the platform should require an out-of-band identity verification — a phone call with your firm's IT admin, or in some cases, physical verification. Not just "click this email link."

Dan: Right. Let me ask the business case question. For a legal SaaS vendor, is MFA just a security feature, or is there a professional obligation here?

Alice: It's both. ABA Model Rule 1.6(c) — which we first mentioned back in Episode 1 — requires lawyers to make reasonable efforts to prevent unauthorised access to client information. A recent ABA survey found that fewer than half of solo and small firm lawyers use MFA at all. Meanwhile, cyber insurance carriers now require MFA on all accounts as a precondition for coverage. If a legal SaaS platform doesn't enforce MFA, it's actively making it harder for its lawyer-customers to meet their ethical obligations and their insurance requirements.

Dan: So the vendor should enforce it, not just offer it?

Alice: Enforce it for everyone. TOTP as the baseline — it's free, every phone can do it. Passkeys as the recommended upgrade for firms handling high-sensitivity matters. And design the recovery flow carefully. Never let SMS-only recovery defeat a hardware key enrolment. Log every MFA event — enrolment, verification, failed attempts, recovery — because auditors and regulators will ask. There's a full comparison table of all the MFA methods with their strengths and weaknesses in the episode notes.

Dan: Mm. Quick real-world reminder for anyone who needs motivating — Colonial Pipeline, 2021. The attackers got in through a single VPN password on a dormant account. No MFA. That was the entire attack surface for an infrastructure company that supplies nearly half the fuel for the US East Coast.

Alice: One password. No second factor. Basic MFA would have stopped it entirely. And the Uber case shows that even when you have MFA, the type matters. Push notifications failed against social engineering. Phishing-resistant MFA — passkeys, hardware keys — would have been immune.

Dan: Next episode — Single Sign-On, SAML, and Enterprise Identity. How law firms centralise authentication across all their SaaS platforms.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.