MFA rezistent la phishing: de ce nu orice al doilea factor este la fel

Autentificarea cu mai mulți factori nu este un singur lucru. Distanța dintre un cod de unică folosință trimis prin SMS și o passkey ancorată în hardware este diferența dintre a încetini un atacator și a-l opri complet. Este distincția dintre MFA phishabil și MFA rezistent la phishing.

De ce cea mai mare parte a MFA este încă phishabilă

Problema codurilor și a solicitărilor push este că al doilea factor este un secret partajat pe care omul îl poate ceda. Dacă un utilizator poate citi un cod și îl poate tasta pe o pagină, poate fi păcălit să îl tasteze pe pagina unui atacator.

• Coduri SMS / TOTP — un proxy atacator la mijloc (AiTM) precum Evilginx prezintă o clonă de login perfectă, transmite credențialele și codul OTP în timp real și captează cookie-ul de sesiune rezultat. Codul valid nu aduce nimic.
• Notificări push — vulnerabile la oboseala MFA / bombardarea cu solicitări: aprobări repetate până când un utilizator obosit atinge „Aprobă”.
• Schimbul de SIM (SIM swapping) — mută numărul victimei pe SIM-ul unui atacator, învingând complet SMS-ul.

Potrivirea numerelor și contextul geografic la push ajută, dar sunt atenuări pe un design fundamental phishabil.

Ce face MFA rezistentă la phishing

MFA rezistentă la phishing scoate omul din decizia de încredere. Contează două proprietăți:

• Ancorarea la origine — credențiala este legată criptografic de exact originea web pentru care a fost înregistrată. Un domeniu asemănător sau proxy pur și simplu nu se potrivește, așa că autentificarea eșuează în tăcere.
• Niciun secret partajat în tranzit — autentificarea folosește o provocare-răspuns cu o cheie privată care nu părăsește niciodată dispozitivul.

Standardele care oferă asta:

• FIDO2 / WebAuthn — standardul de browser și platformă pentru autentificarea cu cheie publică.
• Passkeys — credențiale FIDO2, fie legate de dispozitiv (cheie de securitate hardware, de ex. YubiKey), fie sincronizate (salvate într-un ecosistem de furnizor precum Apple, Google sau un manager de parole).
• PIV / carduri inteligente (x.509) — abordarea consacrată din companii și instituții publice.

De ce proxy-urile AiTM eșuează împotriva ei

Utilizator → phish.example (proxy-ul atacatorului) → real.example

Aserțiunea WebAuthn este semnată peste originea pe care browserul o vede:
  clientDataJSON.origin = "https://phish.example"
Credențiala a fost înregistrată pentru "https://real.example"
→ nepotrivire de origine → autentificatorul/RP respinge aserțiunea

Nu există niciun cod pe care utilizatorul să-l transmită și niciun cookie pe care proxy-ul să-l recolteze, fiindcă login-ul nu reușește niciodată împotriva originii greșite. Browserul impune asta — nu omul.

Desfășurarea fără a strica lucrurile

Prioritizați după risc. Începeți cu administratori, finanțe, conducere și oricine are acces la sistemele cele mai prețioase. Sunt conturile pe care kiturile AiTM le vizează primele.

Planificați recuperarea contului. Recuperarea este noul punct slab — dacă o cheie pierdută revine la SMS sau la un apel către help desk, ați reintrodus calea phishabilă. Cereți doi autentificatori înregistrați per utilizator (de ex. o cheie de securitate plus o passkey de platformă) și întăriți verificarea identității la help desk.

Gestionați parcuri mixte. Passkey-urile sincronizate ușurează desfășurarea pe dispozitive personale și mobile; cheile legate de dispozitiv se potrivesc scenariilor de asigurare înaltă și partajate/chioșc. Multe organizații le folosesc pe amândouă.

Secvențiați migrarea:

1. Activați FIDO2/passkeys alături de MFA existent.
2. Înregistrați un al doilea factor și derulați campanii de înrolare.
3. Treceți rolurile privilegiate la rezistent la phishing obligatoriu.
4. Eliminați SMS-ul și vocea ca factori.
5. Extindeți cerința de rezistență la phishing la toată organizația prin acces condiționat.

Țintiți ca rezistența la phishing să fie obligatorie, nu doar disponibilă. Cât timp există o soluție de rezervă phishabilă, atacatorii îi îndrumă pe utilizatori spre ea — o tehnică numită downgrade de MFA.

Cum ajută GottaPhish

MFA phishabilă — OTP și push — dă un fals sentiment de siguranță lăsând totodată un gol real pe care atacatorii îl exploatează activ; simpla deținere a tehnologiei nu îl închide. GottaPhish și echipa sa de experți vă ajută să construiți argumentul de business și să executați desfășurarea: simulările noastre în stil AiTM demonstrează, în siguranță și măsurabil, cum MFA cu OTP și push cade în fața unui proxy real, oferind conducerii dovada necesară pentru a finanța MFA rezistentă la phishing. De acolo, specialiștii noștri vă ghidează adoptarea FIDO2/passkey direct — prioritizând rolurile cu risc ridicat, planificând înrolarea cu doi autentificatori și recuperarea și raportând adoptarea alături de metricile de clic și de raportare — și vă ajută să interpretați rezultatele, ca să puteți dovedi că golul phishabil chiar se închide.