VPN MFA užklausa atmesta: ką turėtų daryti klientas

Atmesta MFA užklausa atrodo kaip tinklo problema, bet ja nėra. Serveris paprašė antrojo veiksnio, veiksnys grįžo neigiamai arba niekada neatvyko, ir sesija buvo atmesta dar prieš atsirandant bet kokiam tuneliui. Tai, kas vyksta toliau, yra kliento elgsenos klausimas: parodyti klaidą ir leisti vartotojui pradėti švarų bandymą arba kartoti taip, kad atsirastų daugiau užklausų ir galiausiai įsijungtų paskyros apsauga. Antrasis kelias yra tai, kaip vienas neteisingai įvestas kodas tampa užrakinta paskyra.

Patikrinkite, kuri užklausa nepavyko

Pradėkite nuo to, kuri užklausa nepavyko, nustatymo. Push pranešimas, TOTP kodas, FIDO teiginys ir SAML srautas kiekvienas nepavyksta skirtingai, ir klientas paprastai žino, kurio prašė. Atmetimas, pasibaigęs iššūkis ir pristatymo klaida, kuri niekada nepasiekė įrenginio, visi baigiasi ta pačia bendra klaida, todėl skirtumas dažnai išlieka tik pačios kliento būsenoje.

Šią būseną verta užrašyti tiksliai. Užrašykite iššūkio identifikatorių arba operacijos nuorodą, veiksnio tipą, laiko žymą ir rezultatą, bet niekada kodo ar teiginio. Iššūkio identifikatorius yra tai, kas leidžia administratoriui rasti įvykį tapatybės teikėjo pusėje; be jo palaikymo pokalbis prasideda „kažkada per pastarąją valandą“ ir dažniausiai ten baigiasi. Traktuokite jį kaip diagnostinius metaduomenis, o ne kaip paslaptį.

Bandykite dar kartą vieną sykį, sąmoningai, su nauju iššūkiu

Pakartotinis bandymas turėtų būti naujas bandymas su nauju iššūkiu, o ne senojo atkartojimas. Kai klientas pakartotinai naudoja ankstesnį iššūkį, tapatybės teikėjas jį atmeta kaip pasenusį arba, dar blogiau, priima patvirtinimą, skirtą ankstesniam bandymui. Paprašykite naujo iššūkio, parodykite jį ir leiskite vartotojui veikti pagal tą, kuris dabar yra ekrane.

Du bandymai su trumpa pauze tarp jų yra pagrįsta numatytoji reikšmė; neribota kilpa nėra. Jei antrasis bandymas nepavyksta taip pat, sustokite ir praneškite, o ne tęskite.

Ko klientas neturi daryti

Klientas neturi daryti kelių dalykų, kurie atrodo naudingi ir tokie nėra. Jis neturi ir toliau siųsti push pranešimų, kol kas nors nepaspaus „patvirtinti“, nes tai moko vartotojus tvirtinti užklausas, kurių jie nepradėjo, ir būtent tuo elgesiu remiasi phishing rinkiniai. Jis neturi grįžti prie silpnesnio veiksnio todėl, kad stiprusis nepavyko, ir neturi išjungti serverio tapatybės patikros, kad apeitų tuo pačiu metu pasirodžiusį sertifikato skundą. Kiekvienas iš šių trijų trumpinių paverčia autentifikavimo klaidą saugumo incidentu.

Jis taip pat neturi tyliai praryti klaidos. Klientas, kuris užveria ryšį ir rodo sukiklį, palieka vartotoją be jokio supratimo, ar kartoti, laukti, ar skambinti palaikymo tarnybai. Parodykite klaidą su veiksnio tipu ir trumpu kodu, laikykite pranešimą be paslapčių ir padarykite kartojimo veiksmą aiškų, o ne automatinį.

Jei užklausos nepradėjo prie klaviatūros sėdintis asmuo, teisingas veiksmas yra palikti ją atmestą ir pranešti patikrintu palaikymo keliu. Užklausos patvirtinimas norint sustabdyti triukšmą yra nesėkmės modelis, o ne sprendimas.

Ką užrašyti palaikymo tarnybai

Palaikymo tarnybai naudingas įrašas yra mažas. Apytikslis laikas su laiko juosta, paskyra, klientas ir versija, veiksnio tipas ir kiekvieno bandymo ne slapta būsena: paprašyta, atmesta, pasibaigė, patvirtinta, bet politikos atmesta.

Stebėkite ir kliento bei serverio laikrodžius. TOTP yra laiko lango patikra, todėl įrenginys, kurio laikrodis nukrypo, generuoja galiojančiai atrodančius kodus, kurie kaskart nepavyksta, o klientas, kuris praneša apie negaliojantį kodą nepaminėdamas nuokrypio, siunčia žmones iš naujo nustatyti prisijungimo duomenų, kurie niekada nebuvo neteisingi. Vartotojas, kurio prisijungimas nepavyksta pakartotinai, prieš generuodamas daugiau užklausų turėtų patikrinti palaikomą kliento versiją, registracijos būseną ir dokumentuotą atkūrimo srautą.

Atkūrimo kelias nusipelno tokio pat rūpesčio kaip prisijungimo kelias. Pamesto įrenginio darbo eiga egzistuoja būtent tam, kad atmetimas netaptų leidimu apeiti autentifikavimą, ir klientas turėtų nuorodą į dokumentuotą organizacijos procesą, o ne kurti savą.

Taisyklė, pagal kurią reikia statyti: atmetimas yra rezultatas, o ne kliūtis. Praneškite apie jį vieną kartą, aiškiai, su pakankamu kontekstu veikti, ir leiskite kitam bandymui būti naujam. CISA gairės apie phishingui atsparią MFA paaiškina, kodėl modelis „klausk, kol patvirtins“ yra pavojingas nuo pat pradžių, ir tai yra šaltinis, kurį verta cituoti, kai kas nors siūlo kartojimo kilpą. Viskas, ką klientas prideda po atmetimo, turėtų palengvinti žmogui kitą sprendimą, o ne atimti sprendimą iš jo.