MFA rezistent la phishing: passkey-uri vs push vs hardware

TL;DR

• TOTP și SMS nu sunt rezistente la phishing. Un proxy în timp real (atacator-în-mijloc) retransmite codul către site-ul real înainte ca acesta să expire, așa că un cod de 6 cifre furat valorează cât o parolă furată.
• MFA rezistent la phishing leagă credențialul de originea legitimă. Passkey-urile/FIDO2 (WebAuthn) și aprobările push legate de origine refuză să se autentifice către un domeniu care imită originalul, pentru că provocarea criptografică este limitată la cea reală.
• Atestarea este linia de demarcație. Fără atestare hardware, „passwordless” încă acordă încredere unui dispozitiv care ar putea fi rootat, emulat sau clonat. Cheile susținute de hardware dovedesc că credențialul există într-un element securizat.
• Potrivește metoda la nivelul de risc. Push-ul cu potrivire de număr depășește SMS-ul; passkey-urile le depășesc pe amândouă; push-ul atestat hardware sau FIDO2 cu chei legate de dispozitiv este ștacheta pentru acces cu asigurare ridicată (clasă AAL3).

Ce este MFA rezistent la phishing?

MFA rezistent la phishing este autentificarea multifactor care nu poate fi învinsă păcălind un utilizator să introducă un cod pe un site fals, pentru că autentificatorul leagă criptografic fiecare autentificare de originea legitimă și refuză să răspundă unui domeniu controlat de atacator. NIST și CISA rezervă acest termen pentru metode precum FIDO2/WebAuthn și PKI — nu pentru SMS, TOTP sau push de bază.

Distincția contează pentru că „avem MFA” nu mai este o afirmație de securitate semnificativă. Întrebarea pe care o pun acum deopotrivă reglementatorii, auditorii și atacatorii este: care MFA și supraviețuiește unui proxy de phishing în timp real? Ghidul US CISA privind MFA rezistent la phishing este explicit că majoritatea factorilor secundari implementați pot fi atacați prin phishing, iar NIST SP 800-63B leagă cel mai înalt nivel de asigurare al autentificatorului (AAL3) de rezistența la impersonarea verificatorului — care este denumirea formală a rezistenței la phishing.

De ce cedează TOTP și SMS la phishing?

TOTP (codul de 6 cifre din aplicația de autentificare) și parolele unice prin SMS împărtășesc un defect fatal: secretul pe care îl introduce un utilizator nu este legat de locul în care îl introduce. Un cod care dovedește „sunt utilizatorul” către banca reală îl dovedește și oricui îl poate retransmite în fereastra de 30 de secunde. Kiturile moderne de phishing (Evilginx, Modlishka și succesoarele lor) automatizează exact acest lucru: se așază între victimă și site-ul real ca un proxy invers transparent.

Victima ajunge pe bank-secure-login[.]com, își introduce parola, apoi codul TOTP. Proxy-ul le transmite pe ambele către bank.com-ul autentic în timp real, finalizează autentificarea și recoltează cookie-ul de sesiune rezultat. Utilizatorul nu vede niciodată nimic în neregulă. SMS-ul este și mai rău — adaugă SIM-swap și interceptarea SS7 peste aceeași slăbiciune de retransmitere, motiv pentru care NIST a descurajat ani de zile SMS-ul ca autentificator restricționat.

Cum se citește diagrama: Jumătatea de sus arată un flux de phishing atacator-în-mijloc (AITM) în timp real împotriva unui factor secundar bazat pe cod. Pentru că codul TOTP sau SMS nu poartă nicio informație despre care site l-a solicitat, proxy-ul pur și simplu retransmite totul către serviciul real și pleacă cu un cookie de sesiune activ. Jumătatea de jos arată același atac împotriva unui credențial legat de origine: ceremonia WebAuthn/passkey încorporează originea părții care se bazează (relying-party) în ceea ce semnează autentificatorul, astfel încât, atunci când dispozitivul vede un domeniu care imită originalul, nu produce nicio aserțiune validă. Lecția este că rezistența la phishing nu ține de lungimea codului sau de entropie — ține de faptul că credențialul este sau nu limitat criptografic la originea legitimă. Aceasta este singura proprietate care separă MFA atacabil prin phishing de MFA rezistent la phishing.

Care sunt candidații?

Există trei familii care merită comparate pentru orice implementare din 2026.

Passkey-uri / FIDO2 (WebAuthn). Un passkey este un credențial FIDO2 detectabil (discoverable) — o pereche de chei publică/privată în care cheia privată nu părăsește niciodată autentificatorul (un element securizat al telefonului, un TPM al platformei sau o cheie de securitate roaming). Browserul execută ceremonia W3C WebAuthn, care semnează o provocare împreună cu ID-ul părții care se bazează (relying-party) și originea. Pentru că originea face parte din datele semnate, un passkey provizionat pentru bank.com este structural inutilizabil împotriva bank-secure-login[.]com. Specificațiile FIDO Alliance stau la baza acestui model. Passkey-urile sunt standardul de aur pentru rezistența la phishing și oferă o experiență de utilizare excelentă (o amprentă sau o scanare facială), dar varianta sincronizabilă (sincronizată printr-un cloud al platformei) sacrifică o parte din puterea legării de dispozitiv în favoarea recuperabilității.

Push cu potrivire de număr. Notificările push de tip tap-to-approve au fost larg implementate, dar au suferit de „oboseală MFA” — atacatorii spamează aprobările până când un utilizator obosit apasă „da”. Potrivirea de număr închide această breșă: ecranul de autentificare afișează un număr pe care utilizatorul trebuie să îl introducă în prompt, astfel încât o aprobare oarbă nu poate reuși. Implementat corect, push-ul poate fi și conștient de origine — aprobarea este legată de sesiunea specifică și de contextul părții care se bazează (relying-party), nu doar de un „da/nu”. Push-ul cu potrivire de număr este o îmbunătățire majoră de experiență și securitate față de SMS, dar rezistența sa la phishing depinde în întregime de faptul că aprobarea este sau nu legată de originea reală și că dispozitivul este de încredere.

Legare de dispozitiv atestată hardware. Acesta este stratul pe care majoritatea comparațiilor îl ratează. Indiferent dacă folosești un passkey sau o aprobare push, securitatea se prăbușește dacă cheia privată trăiește pe un dispozitiv rootat, emulat sau infestat cu malware. Atestarea hardware — prin Android StrongBox, un TEE sau Secure Enclave de la Apple — permite furnizorului de identitate să verifice că cheia a fost generată într-un element securizat certificat și că dispozitivul nu este compromis, validând un lanț de certificate până la rădăcina producătorului platformei. Documentația Android Key Attestation descrie cum acest lanț dovedește proveniența cheii.

Cum se compară passkey-urile, push-ul și MFA hardware?

Matricea de mai jos punctează fiecare metodă pe cele patru proprietăți care decid de fapt implementarea: rezistența la phishing, legarea de dispozitiv, experiența de utilizare și recuperabilitatea.

Cum se citește diagrama: Acesta este un flux de decizie care clasează fiecare familie de MFA după cele două întrebări care contează cel mai mult. Prima poartă — este credențialul legat de origine? — separă imediat metodele atacabile prin phishing (SMS, TOTP) de toate celelalte, indiferent cât de șlefuită este experiența de utilizare. A doua poartă — este legat de un dispozitiv de încredere și este integritatea acelui dispozitiv dovedită prin atestare hardware? — este locul unde opțiunile cele mai puternice se desprind. Observă că două metode pot fi ambele „rezistente la phishing”, dar pot ajunge în niveluri de securitate foarte diferite: un push cu potrivire de număr și o cheie FIDO2 legată de dispozitiv rezistă amândouă la atacul de retransmitere, dar numai calea atestată poate respinge un dispozitiv rootat sau emulat. Nodurile terminale fac explicit punctul inițial: fără atestare, chiar și un passkey acordă încredere unui dispozitiv a cărui integritate nu ai verificat-o niciodată.

De ce este atestarea linia de demarcație?

Cea mai mare parte a marketingului „passwordless” se oprește la „cheia privată nu părăsește niciodată dispozitivul”. Acest lucru este necesar, dar nu suficient. Întrebarea fără răspuns este: ce este dispozitivul? Dacă un atacator poate extrage sau clona cheia pe un telefon rootat, poate rula autentificatorul într-un emulator sau poate încărca lateral (sideload) o versiune modificată, atunci „cheia nu părăsește niciodată dispozitivul” nu garantează nimic — pentru că dispozitivul însuși este ostil.

Atestarea hardware răspunde la acea întrebare. Atunci când autentificatorul își generează cheia într-un StrongBox, TEE sau Secure Enclave, platforma emite un certificat de atestare semnat care dovedește proveniența cheii și starea de boot a dispozitivului. Furnizorul de identitate validează acel lanț și poate respinge dispozitivele rootate, emulatoarele și bootloaderele deblocate înainte de a emite vreun token. Aceasta este diferența dintre a avea încredere într-o afirmație și a o verifica. Pentru o tratare mai aprofundată a modului în care se verifică lanțul de certificate de atestare, vezi articolul nostru complementar despre atestarea hardware pentru autentificare. Atestarea este și locul unde semnarea post-cuantică și încrederea în dispozitiv converg în următorii ani — ghidul de autentificare post-cuantică explică de ce cheia de semnare a furnizorului tău de identitate este primul activ pe care îl țintește un viitor adversar cuantic, ceea ce face ca integritatea dispozitivului care îți deține cheile să fie la fel de critică.

Aceasta este exact alegerea de design din spatele aprobării push atestate hardware de la CAI-AUTH: un flux passwordless de tip tap-to-approve în care dispozitivul care aprobă trebuie să treacă o atestare obligatorie Android StrongBox/TEE, astfel încât dispozitivele rootate și emulate sunt respinse din start, nu doar semnalate cu un avertisment. CAI Technology nu este o autoritate guvernamentală. Aceeași postură — rezistentă la phishing prin legarea de origine, legată de hardware prin atestare și rezistentă la modificări în jurnalul de audit — este ceea ce face metoda auditabilă în raport cu regimurile UE; vezi lista de verificare a autentificării pentru DORA, NIS2 și PSD3 pentru modul în care cerințele de autentificare puternică și de jurnalizare se mapează pe aceste capabilități, precum și comparația alternative la Okta și Auth0 pentru companiile din UE pentru modul în care suveranitatea și atestarea cântăresc în alegerea furnizorului.

Cum ar trebui să aleg pentru nivelul meu de risc?

Potrivește metoda cu ceea ce protejezi. Pentru conturile de consumatori cu risc redus, passkey-urile sincronizabile oferă rezistență la phishing cu recuperare fără fricțiuni și reprezintă o îmbunătățire clară față de SMS. Pentru accesul forței de muncă și cel privilegiat, preferă passkey-urile legate de dispozitiv sau push-ul cu potrivire de număr cu atestare hardware impusă, pentru că un dispozitiv de administrator rootat este un rezultat mult mai rău decât o poveste de recuperare puțin mai dificilă. Pentru sarcinile reglementate (finanțe, infrastructură critică, orice se mapează pe AAL3 sau pe autentificarea puternică a clientului din PSD3), impune legarea de origine și atestarea, jurnalizează fiecare aprobare într-un traseu rezistent la modificări și asigură o cale de recuperare curată — recuperare socială de tip Shamir sau reînrolare atestată — astfel încât legarea puternică de dispozitiv să nu devină un risc de disponibilitate. Dacă te gândești dacă să rulezi singur acest stack, compromisurile legate de auto-găzduirea furnizorului tău de identitate acoperă latura operațională și de suveranitate a deciziei.

Întrebări frecvente

Ce este MFA rezistent la phishing?

MFA rezistent la phishing este autentificarea care nu poate fi retransmisă de un site fals, pentru că credențialul este legat criptografic de originea legitimă. Metode precum passkey-urile FIDO2/WebAuthn și aprobările push legate de origine se califică; SMS-ul, TOTP-ul și push-ul de bază nu, pentru că codurile lor pot fi retransmise în timp real de un proxy atacator-în-mijloc.

Sunt passkey-urile rezistente la phishing?

Da. Passkey-urile sunt credențiale FIDO2/WebAuthn a căror cheie privată semnează o provocare împreună cu originea părții care se bazează (relying-party), astfel încât un passkey provizionat pentru domeniul real nu produce nicio aserțiune validă pe un site care imită originalul. Retransmiterea de phishing pur și simplu eșuează. Passkey-urile legate de dispozitiv adaugă o legare de dispozitiv mai puternică decât cele sincronizate în cloud, cu prețul unei recuperări puțin mai dificile.

Este MFA prin notificare push sigur?

Depinde de implementare. Push-ul de bază de tip tap-to-approve este vulnerabil la spamul de oboseală MFA și este rezistent la phishing doar dacă aprobarea este legată de originea reală. Potrivirea de număr învinge aprobările oarbe, iar adăugarea atestării hardware obligatorii permite furnizorului să respingă dispozitivele rootate sau emulate — ceea ce ridică push-ul la încredere de asigurare ridicată, clasă AAL3.

Vezi o autentificare rezistentă la phishing și atestată hardware în acțiune: explorează aprobarea push atestată hardware de la CAI-AUTH — un furnizor OIDC operat în UE și auto-găzduibil, care respinge prin design dispozitivele rootate și emulate. CAI Technology nu este o autoritate guvernamentală. (CAI TECHNOLOGY SRL, CUI 50512457.)