Cerere MFA pentru VPN respinsă: ce ar trebui să facă clientul

O cerere MFA respinsă pare o problemă de rețea și nu este. Serverul a cerut un al doilea factor, factorul a revenit negativ sau nu a ajuns niciodată, iar sesiunea a fost refuzată înainte de a exista vreun tunel. Ce se întâmplă în continuare este o chestiune de comportament al clientului: să expună eroarea și să lase utilizatorul să înceapă o încercare curată, sau să reîncerce în moduri care generează mai multe cereri și ajung să declanșeze protecția contului. A doua cale este cea prin care un cod tastat greșit devine un cont blocat.

Verificați care cerere a eșuat

Începeți prin a identifica care cerere a eșuat. O notificare push, un cod TOTP, o aserțiune FIDO și un flux SAML eșuează fiecare altfel, iar clientul știe de obicei pe care a cerut-o. Un refuz, o provocare expirată și o eroare de livrare care nu a ajuns niciodată la dispozitiv se termină toate în aceeași eroare generică, așa că starea clientului însuși este adesea singurul loc în care diferența supraviețuiește.

Acea stare merită înregistrată precis. Înregistrați identificatorul provocării sau referința tranzacției, tipul de factor, marca temporală și rezultatul, dar niciodată codul sau aserțiunea. Identificatorul provocării este ceea ce îi permite unui administrator să găsească evenimentul la furnizorul de identitate; fără el, conversația cu suportul începe cu „undeva în ultima oră” și de obicei se termină acolo. Tratați-l ca metadate de diagnostic, nu ca pe un secret.

Reîncercați o dată, deliberat, cu o provocare nouă

O reîncercare ar trebui să fie o încercare nouă cu o provocare nouă, nu o reluare a celei vechi. Când clientul refolosește provocarea anterioară, furnizorul de identitate fie o respinge ca expirată, fie, mai rău, acceptă o aprobare destinată încercării anterioare. Cereți o provocare proaspătă, afișați-o și lăsați utilizatorul să acționeze pe cea care este acum pe ecran.

Două încercări cu o pauză scurtă între ele sunt o valoare implicită rezonabilă; o buclă nelimitată nu este. Dacă a doua încercare eșuează la fel, opriți-vă și raportați în loc să continuați.

Ce nu trebuie să facă clientul

Clientul nu trebuie să facă mai multe lucruri care par utile și nu sunt. Nu trebuie să continue să trimită notificări push până când cineva atinge „aprobă”, pentru că asta îi învață pe utilizatori să aprobe cereri pe care nu le-au inițiat și este exact comportamentul pe care se bazează kiturile de phishing. Nu trebuie să treacă la un factor mai slab pentru că cel puternic a eșuat și nu trebuie să dezactiveze verificarea identității serverului pentru a ocoli o reclamație legată de certificat apărută în același timp. Fiecare dintre aceste trei scurtături transformă o eroare de autentificare într-un incident de securitate.

Nu trebuie nici să înghită eroarea în tăcere. Un client care închide conexiunea și afișează un indicator de încărcare lasă utilizatorul fără nicio idee dacă să reîncerce, să aștepte sau să sune la suport. Afișați eroarea cu tipul de factor și un cod scurt, păstrați mesajul fără secrete și faceți acțiunea de reîncercare explicită în loc de automată.

Dacă cererea nu a fost inițiată de persoana de la tastatură, acțiunea corectă este să o lăsați respinsă și să o raportați prin calea de suport verificată. Aprobarea unei cereri pentru a opri zgomotul este modelul de eșec, nu soluția.

Ce să înregistrați pentru suport

Pentru suport, înregistrarea utilă este mică. Ora aproximativă cu fusul orar, contul, clientul și versiunea, tipul de factor și starea ne-secretă a fiecărei încercări: cerut, refuzat, expirat, aprobat dar respins de politică.

Aveți în vedere și ceasurile clientului și ale serverului. TOTP este o verificare a ferestrei de timp, așa că un dispozitiv cu ceasul deplasat produce coduri cu aspect valid care eșuează de fiecare dată, iar un client care raportează un cod invalid fără să menționeze deplasarea trimite oamenii să reseteze credențiale care nu au fost niciodată greșite. Un utilizator a cărui autentificare eșuează repetat ar trebui să verifice versiunea de client acceptată, starea de înregistrare și fluxul de recuperare documentat înainte de a genera mai multe cereri.

Calea de recuperare merită aceeași grijă ca calea de autentificare. Un flux pentru dispozitiv pierdut există exact pentru ca un refuz să nu devină permisiunea de a ocoli autentificarea, iar clientul ar trebui să facă legătura la procesul documentat al organizației în loc să improvizeze unul.

Regula pe care trebuie construit este că refuzul este un rezultat, nu un obstacol. Raportați-l o dată, clar, cu suficient context pentru a acționa, și lăsați următoarea încercare să fie nouă. Îndrumările CISA despre MFA rezistent la phishing explică de ce modelul „întreabă până la aprobare” este periculos de la bun început, și este referința care merită citată atunci când cineva propune o buclă de reîncercări. Tot ce adaugă clientul după un refuz ar trebui să facă următoarea decizie mai ușoară pentru un om, nu să-i ia decizia.