VPN-i MFA-taotlus tagasi lükatud: mida peaks klient tegema

Tagasi lükatud MFA-taotlus näeb välja nagu võrguprobleem, kuid ei ole seda. Server küsis teist faktorit, faktor tuli negatiivsena tagasi või ei jõudnudki kohale ning seanss lükati tagasi enne, kui ükski tunnel olemas oli. Mis edasi juhtub, on kliendi käitumise küsimus: näidata viga ja lasta kasutajal alustada puhast katset või korrata viisil, mis tekitab rohkem taotlusi ja lõpuks käivitab konto kaitse. Teine tee on see, kuidas üks valesti sisestatud kood muutub lukustatud kontoks.

Kontrollige, milline taotlus ebaõnnestus

Alustage selle kindlakstegemisest, milline taotlus ebaõnnestus. Push-teade, TOTP-kood, FIDO-tõend ja SAML-voog ebaõnnestuvad igaüks erinevalt ning klient teab tavaliselt, millist neist ta küsis. Keeldumine, aegunud väljakutse ja tarnevead, mis kunagi seadmeni ei jõudnud, lõpevad kõik sama üldise veaga, nii et kliendi enda olek on sageli ainus koht, kus erinevus püsib.

Seda olekut tasub täpselt logida. Logige väljakutse identifikaator või tehingu viide, faktori tüüp, ajatempel ja tulemus, kuid mitte kunagi kood ega tõend. Väljakutse identifikaator on see, mis võimaldab administraatoril sündmust identiteedipakkuja poolel leida; ilma selleta algab tugivestlus sõnadega „kusagil viimase tunni jooksul“ ja lõpeb tavaliselt seal. Käsitlege seda diagnostilise metaandmena, mitte saladusena.

Korrake üks kord, teadlikult, uue väljakutsega

Korduskatse peaks olema uus katse uue väljakutsega, mitte vana kordamine. Kui klient kasutab eelmist väljakutset uuesti, lükkab identiteedipakkuja selle kas aegununa tagasi või, mis hullem, aktsepteerib kinnituse, mis oli mõeldud varasema katse jaoks. Küsige värske väljakutse, näidake seda ja laske kasutajal tegutseda selle põhjal, mis praegu ekraanil on.

Kaks katset lühikese pausiga nende vahel on mõistlik vaikeväärtus; piiramatu tsükkel ei ole. Kui teine katse ebaõnnestub samamoodi, peatuge ja teatage, mitte ärge jätkake.

Mida klient ei tohi teha

Klient ei tohi teha mitut asja, mis näivad kasulikud ja ei ole. Ta ei tohi saata push-teateid seni, kuni keegi puudutab „kinnita“, sest see õpetab kasutajaid kinnitama taotlusi, mida nad ei algatanud, ja see on täpselt see käitumine, millele phishing-komplektid tuginevad. Ta ei tohi langeda nõrgemale faktorile, sest tugev ebaõnnestus, ega lülitada välja serveri identiteedi kontrolli, et mööda minna samal ajal ilmnenud sertifikaadikaebusest. Kõik need kolm lõiketeed muudavad autentimisvea turvaintsidendiks.

Samuti ei tohi ta viga vaikselt alla neelata. Klient, kes sulgeb ühenduse ja näitab spinnerit, jätab kasutaja ilma igasuguse aimduseta, kas proovida uuesti, oodata või tugiteenust helistada. Näidake viga faktori tüübi ja lühikese koodiga, hoidke sõnum saladustest vaba ja tehke kordamise tegevus selgesõnaliseks, mitte automaatseks.

Kui taotlust ei algatanud klaviatuuri taga istuv inimene, on õige tegevus jätta see tagasi lükatuks ja teatada sellest kontrollitud tugitee kaudu. Taotluse kinnitamine müra lõpetamiseks on ebaõnnestumise muster, mitte lahendus.

Mida tugiteenuse jaoks logida

Tugiteenuse jaoks on kasulik kirje väike. Ligikaudne aeg koos ajavööndiga, konto, klient ja versioon, faktori tüüp ning iga katse mitte-salajane olek: küsitud, keeldutud, aegunud, kinnitatud, kuid poliitikaga tagasi lükatud.

Hoidke silma peal ka kliendi ja serveri kelladel. TOTP on ajavahemiku kontroll, nii et nihkunud kellaga seade tekitab kehtivatena näivaid koode, mis iga kord ebaõnnestuvad, ja klient, kes teatab kehtetust koodist nihet mainimata, saadab inimesi lähtestama volitusi, mis ei olnud kunagi valed. Kasutaja, kelle sisselogimine korduvalt ebaõnnestub, peaks enne uute taotluste tekitamist kontrollima toetatud kliendi versiooni, registreerimise olekut ja dokumenteeritud taastamisvoogu.

Taastamistee väärib sama hoolt kui sisselogimistee. Kadunud seadme töövoog on olemas just selleks, et keeldumisest ei saaks autentimisest möödamineku luba, ja klient peaks linkima organisatsiooni dokumenteeritud protsessile, mitte improviseerima oma.

Reegel, mille vastu ehitada, on see, et keeldumine on tulemus, mitte takistus. Teatage sellest üks kord, selgelt, piisava kontekstiga tegutsemiseks, ja laske järgmisel katsel olla uus. CISA juhised phishingile vastupidava MFA kohta selgitavad, miks muster „küsi, kuni kinnitatakse“ on algusest peale ohtlik, ja see on viide, mida tasub tsiteerida, kui keegi pakub välja korduskatsete tsükli. Kõik, mida klient pärast keeldumist lisab, peaks tegema järgmise otsuse inimese jaoks lihtsamaks, mitte otsust tema käest ära võtma.