Două solicitări de parolă nu sunt MFA: ce verifică o autentificare VPN
Un al doilea câmp de parolă, o criptare puternică și un certificat de dispozitiv dovedesc fiecare ceva. Doar factorii distincți legați de un singur cont contează ca multifactori.
Pagina de autentificare cere o parolă, apoi un al doilea secret, iar implementarea este descrisă imediat ca multifactor. Uneori chiar este. Adesea este un singur factor colectat de două ori, pentru că ambele valori sunt cunoștințe pe care aceeași persoană le-a tastat din aceeași memorie sau din aceeași notă. O criptare puternică a tunelului nu schimbă asta, nici cuvântul „sigur” din numele produsului.
Separarea afirmației de mecanism cere o singură întrebare: ce dovedește fiecare pas și cui?
Un factor este o dovadă, nu un câmp
Autentificarea multifactor înseamnă că pentru același cont se verifică mai mult de un tip distinct de dovadă: ceva ce utilizatorul știe, ceva ce deține, ceva ce este. Două câmpuri care colectează amândouă un șir memorat sunt un singur tip de dovadă cerut de două ori. Poate fi un control util, fiindcă două secrete independente sunt mai greu de ghicit decât unul, dar nu este ceea ce descrie termenul și nu ar trebui numărat ca atare într-o evaluare de risc.
Partea de verificare contează la fel de mult ca partea de colectare. Un cod generat pe un dispozitiv dovedește controlul asupra acelui dispozitiv doar dacă serverul îl verifică față de un secret legat de acest cont și respinge reluările. Un cod partajat care funcționează pentru toți, un cod fără limită și o solicitare aprobată pe un dispozitiv care nu arată niciodată ce se aprobă sunt toate mai slabe decât sugerează eticheta.
Așadar, când cineva întreabă dacă VPN-ul are MFA, întrebați ce dovedește al doilea pas și cum îl leagă serverul. Dacă răspunsul este „o a doua parolă din același director”, aveți un factor și o conversație despre politică, nu un al doilea factor.
Cazul certificatului trebuie citit, nu presupus
Un certificat de client plus o parolă arată ca doi factori și poate fi: certificatul este ținut într-un depozit sau pe un token, iar parola este memorată. Poate fi și unul singur, dacă fișierul certificatului stă neprotejat în același director de profil ca parola salvată, sau dacă certificatul a fost emis pentru un dispozitiv pe care mai multe persoane îl împart fără responsabilitate individuală.
Întrebarea de lămurit este pe cine sau ce identifică certificatul. Un certificat de dispozitiv dovedește că o mașină administrată este prezentă. Un certificat de utilizator dovedește o identitate. Dacă implementarea emite un certificat pentru fiecare laptop și apoi tratează prezența lui ca dovadă a persoanei, al doilea factor a devenit în tăcere o proprietate a hardware-ului pe care o moștenește oricine ține laptopul.
Nimic din toate acestea nu face certificatele o idee proastă. Face distincția dintre garanția dispozitivului și garanția utilizatorului demnă de scris, fiindcă cele două răspund la întrebări diferite, iar o foaie de calcul de conformitate care le numără ca una va supraestima ce este protejat.
Încrederea în gateway și încrederea în utilizator sunt probleme separate
Un al doilea factor nu face sigură tastarea acreditivelor într-un punct final pe care nu l-ați verificat. Clientul trebuie să recunoască gateway-ul dorit, iar pentru asta sunt certificatul serverului și configurația de încredere a clientului. Phishing-ul funcționează mutând autentificarea pe un server controlat de atacator, iar un cod de unică folosință corect introdus acolo este pur și simplu retransmis serviciului real în timp real.
De aceea alegerea metodei schimbă rezultatul mai mult decât formularea solicitării. Codurile tastate de o persoană pot fi retransmise de oricine poate afișa o pagină convingătoare, în timp ce metodele criptografice care leagă autentificarea de originea și sesiunea concrete rezistă acestei retransmiteri prin proiectare. Care dintre ele există la dumneavoastră este o proprietate a metodei, nu a numărului de pași din dialog.
Urmați fluxul de înregistrare și de client acceptat de furnizor, în loc să înșurubați o solicitare suplimentară pe un câmp de parolă. Un al doilea pas făcut acasă ajunge de obicei undeva la mijloc, adăugând frecare fără legătura care face factorul semnificativ.
Recuperarea este a doua ușă din față
Orice autentificare puternică are o cale de întoarcere când autentificatorul se pierde, iar acea cale este de obicei punctul cel mai slab al proiectării. Dacă un agent de suport poate reseta al doilea factor după un telefon la un număr din evidență, ruta cea mai ieftină pentru atacator este serviciul de asistență, nu pagina de autentificare.
Întrebați cum funcționează înlocuirea, cine o aprobă și ce dovezi se cer. Apoi verificați că materialul de recuperare, cum ar fi codurile de rezervă, este păstrat separat de acreditivul principal, astfel încât o singură compromitere să nu le predea pe amândouă. Îndrumările NIST privind identitatea digitală tratează legarea verificatorului și ciclul de viață al autentificatorului ca parte a cerinței, nu ca un gând operațional ulterior.
Ce să scrieți în evaluare
Descrieți factorii după tip, numiți ce dovedește fiecare și precizați cum este legat de cont. Notați dacă metoda rezistă retransmiterii și descrieți calea de recuperare cu aceeași grijă ca autentificarea.
Apoi spuneți clar dacă implementarea este multifactor conform acelei definiții. „Două parole și un certificat de mașină” este o propoziție onestă și îi spune cititorului mult mai mult decât o casetă de bifare care spune da.