NSM anbefaler overgang til phishingresistent autentisering
Så klart, fordi det er kjempeviktig. Og det fungerer, men har det noen svakheter? Vel, FIDO2, phishing resistent autentisering, i seg selv fungerer nok ganske bra, men er det alene nok? Nei, det er det ikke.
Mennesker og teknologi
Å innføre FIDO2 er anbefalt til alle for bedre motstandskraft mot phishing, som er relevant for alle i forbindelse med svindel og løsepengeangrep.
Å innføre brukervennlig FIDO2 er veldig viktig, for her er det store forskjeller. Om man installerer en FIDO2 løsning uten å legge stor nok vekt på brukervennlighet ender man opp med en løsning som teknisk sett fungerer, men det blir enda en sikkerhetsløsning som skaper frustrasjon.
Sikre trening i forbindelse med FIDO2
Om en bruker får en phishing e-post, blir lurt og prøver å logge inn, så vil FIDO2 hindre at man klarer det. Men om brukeren er helt overbevist om at dette er en gyldig side så kan alternative innloggingsmetoder være sårbarheten. Tenk om brukeren også kan logge inn med Authenticator? Da er man plutselig like langt. Og dette er hele essensen med denne posten.
Hva sier ChatGPT?
NB! Jeg har ikke dobbelsjekket alt i svaret, men det er allikevel ikke så viktig, da hovedpoenget med denne artikkelen er å skape bevissthet på sårbarheter rundt muligheter med å omgå FIDO2 og viktigheten av at dette adresseres.
Jeg spurte følgende for å lære mer om FIDO2:
How does a fido2 security key protect against man in the middle, or Adversary in the middle, attacks? Traditionally attackers are able to get the session cookie. Why doesn’t it work with fido2?
Her fikk jeg mye bra informasjon som forklarte hvordan og hvorfor det fungerer. Her er en kort oppsummering:
What FIDO2 changes at a fundamental level
FIDO2 replaces shared secrets with asymmetric cryptography + origin binding.
Key properties:
🔐 Private key never leaves the authenticator
🌐 Credentials are scoped to a specific origin
🔗 Authentication is bound to the TLS channel
✋ User presence / verification is required
This combination kills MitM attacks.
Og så spurte jeg:
What if the user are fooled by a phishing email and tries to log in, but can’t, so a fallback to Authenticator makes the user able to log in?
Og det er her jeg fikk det svaret jeg forventet, men også informasjon om hva man bør gjøre, og det er dette siste som er meget viktig:
This is an excellent question, because it hits the exact place where FIDO2 deployments fail in practice.
Short answer up front:
If you allow a weaker fallback (TOTP / Authenticator) on the same account, phishing resistance is broken — even if FIDO2 itself is perfect.
Now let’s unpack why, and what to do about it.
1. What actually happens in your scenario
The attack flow:
- User receives a phishing email.
- Attacker hosts a proxy phishing site (Evilginx-style).
- User tries to log in with FIDO2.
- FIDO2 correctly fails:
- Wrong origin
- Authenticator refuses to sign
- Site offers a fallback: “Try another method” → Authenticator App (TOTP)
- User enters:
- Username
- Password
- TOTP code
- Attacker relays:
- Password
- TOTP (valid for ~30 seconds)
- Attacker gets:
- Valid session cookie
- Full account access
🎯 Attack succeeds — not by breaking FIDO2, but by bypassing it.
2. Why fallback MFA destroys phishing resistance
FIDO2 is not just “strong MFA”
It’s a different security model.
| Factor | Password/TOTP | FIDO2 |
|---|---|---|
| Secret | Shared | Asymmetric |
| Replayable | Yes | No |
| Origin-bound | No | Yes |
| Phish-resistant | ❌ | ✅ |
When you allow fallback to TOTP:
- You reintroduce shared secrets
- You re-enable real-time replay
- You undo origin binding
📌 The attacker doesn’t need to defeat FIDO2 — only convince the user to avoid it.
3. This is not theoretical — it’s how real breaches happen
This exact pattern caused compromises at:
- Cloud providers
- Identity providers
- Crypto exchanges
- SaaS platforms
Common postmortem sentence:
“FIDO2 was enabled, but users could fall back to SMS/TOTP.”
From an attacker’s perspective:
- Fallback = open door
- FIDO2 = speed bump
4. Why users will choose the fallback
Even well-trained users:
- Assume the site is legit
- Trust the UI
- Want to get their work done
- Think “the key must be broken”
Phishing success relies on:
- Confusion, not stupidity
5. Security principle: weakest allowed path wins
Authentication is only as strong as:
The weakest method that can grant a session
If any path allows:
- Password + TOTP
- Password + SMS
- Push approval
Then:
- The account is phishable
- Session cookies are stealable
- AitM works again
6. What secure systems do instead
✅ 1. Make FIDO2 mandatory (no fallback)
For high-risk users:
- Admins
- Developers
- Finance
- Execs
If FIDO2 fails:
- Login fails
- Support process required
Yes, this is painful.
Yes, this is painful.
It is also secure.
✅ 2. Split fallback by risk & scope
If fallback must exist:
- Allow fallback only for account recovery
- Require:
- Cool-down period
- Identity verification
- New session (no cookie reuse)
- Revoke all existing sessions
Never allow:
- Real-time fallback on the same login screen
✅ 3. Step-up policies
Example:
- FIDO2 required for:
- New devices
- New locations
- Privileged actions
- TOTP only allowed:
- On already-bound, known devices
This limits phishing blast radius.
✅ 4. Enforce per-account “phishing-resistant required”
Modern IdPs support:
- Authentication Strength policies
- “Phishing-resistant MFA only”
If:
- Account is marked “FIDO-only” Then:
- TOTP/SMS are disabled entirely
7. UX patterns that help users do the right thing
Good systems:
- Hide fallback by default
- Show warning like: “This method is not phishing-resistant”
- Require extra confirmation: “You are bypassing your security key”
Bad systems:
- Put “Try another way” in big friendly text
8. Key insight to remember
FIDO2 doesn’t fail — policy fails.
The cryptography works.
The browser works.
The authenticator works.
But if you let users escape to weaker auth:
- Attackers will herd them there
- And win every time
Final takeaway
Allowing TOTP/SMS fallback on a FIDO2-protected account reintroduces phishing and Adversary-in-the-Middle attacks.
To be phishing-resistant in practice, you must:
- Make FIDO2 mandatory for authentication
- Treat fallback as recovery, not login
- Bind sessions tightly and revoke aggressively
Leave a Reply