Zahteva MFA za VPN zavrnjena: kaj naj stori odjemalec

Zavrnjena zahteva MFA je videti kot omrežna težava in ni. Strežnik je zahteval drugi dejavnik, dejavnik se je vrnil negativno ali sploh ni prispel, seja pa je bila zavrnjena, preden je obstajal kakršen koli tunel. Kar se zgodi potem, je vprašanje vedenja odjemalca: razkriti napako in pustiti uporabniku, da začne čist poskus, ali ponavljati na načine, ki ustvarjajo več zahtev in na koncu sprožijo zaščito računa. Druga pot je tista, na kateri en napačno vtipkan kod postane zaklenjen račun.

Preverite, katera zahteva ni uspela

Začnite s prepoznavanjem, katera zahteva ni uspela. Potisno obvestilo, koda TOTP, trditev FIDO in tok SAML vsak ne uspejo drugače, odjemalec pa običajno ve, katero je zahteval. Zavrnitev, potekel izziv in napaka pri dostavi, ki ni nikoli dosegla naprave, se vsi končajo z isto splošno napako, zato razlika pogosto preživi le v stanju samega odjemalca.

To stanje je vredno natančno zabeležiti. Zabeležite identifikator izziva ali referenco transakcije, vrsto dejavnika, časovni žig in izid, nikoli pa kode ali trditve. Identifikator izziva je tisto, kar skrbniku omogoči, da dogodek najde na strani ponudnika identitete; brez njega se pogovor s podporo začne z »nekje v zadnji uri« in se običajno tam tudi konča. Obravnavajte ga kot diagnostične metapodatke, ne kot skrivnost.

Poskusite znova enkrat, namerno, z novim izzivom

Ponovni poskus naj bo nov poskus z novim izzivom, ne predvajanje starega. Ko odjemalec znova uporabi prejšnji izziv, ponudnik identitete tega zavrne kot zastarelo ali, kar je slabše, sprejme odobritev, namenjeno prejšnjemu poskusu. Zahtevajte svež izziv, prikažite ga in pustite uporabniku, da deluje na tistem, ki je zdaj na zaslonu.

Dva poskusa s kratkim premorom med njima sta razumna privzeta vrednost; neomejena zanka ni. Če drugi poskus spodleti enako, se ustavite in poročajte, namesto da nadaljujete.

Česa odjemalec ne sme storiti

Odjemalec ne sme storiti več stvari, ki so videti koristne in niso. Ne sme nadaljevati s pošiljanjem potisnih obvestil, dokler nekdo ne tapne »odobri«, ker to uči uporabnike odobravati zahteve, ki jih niso začeli, in natanko na to vedenje računajo phishing kompleti. Ne sme se vrniti na šibkejši dejavnik, ker je močnejši spodletel, in ne sme izklopiti preverjanja identitete strežnika, da bi obšel pritožbo glede potrdila, ki se je pojavila hkrati. Vsaka od teh treh bližnjic spremeni neuspeh preverjanja pristnosti v varnostni incident.

Prav tako ne sme tiho pogoltniti neuspeha. Odjemalec, ki zapre povezavo in prikaže vrtavko, pusti uporabnika brez pojma, ali naj poskusi znova, počaka ali pokliče podporo. Prikažite neuspeh z vrsto dejavnika in kratko kodo, ohranite sporočilo brez skrivnosti in naredite dejanje ponovnega poskusa izrecno, ne samodejno.

Če zahteve ni začela oseba za tipkovnico, je pravilno dejanje pustiti jo zavrnjeno in jo prijaviti po preverjeni poti podpore. Odobritev zahteve, da bi ustavili hrup, je vzorec neuspeha, ne rešitev.

Kaj zabeležiti za podporo

Za podporo je koristen zapis majhen. Približen čas s časovnim pasom, račun, odjemalec in različica, vrsta dejavnika in nejavni status vsakega poskusa: zahtevano, zavrnjeno, poteklo, odobreno, a zavrnjeno s politiko.

Imejte pred očmi tudi uri odjemalca in strežnika. TOTP je preverjanje časovnega okna, zato naprava z zamaknjeno uro ustvari kode, ki so videti veljavne in vsakič spodletijo, odjemalec, ki poroča o neveljavni kodi brez omembe zamika, pa pošilja ljudi ponastavljati poverilnice, ki nikoli niso bile napačne. Uporabnik, ki mu prijava večkrat spodleti, bi moral preveriti podprto različico odjemalca, stanje vpisa in dokumentiran potek obnovitve, preden ustvari več zahtev.

Pot obnovitve si zasluži enako skrb kot pot prijave. Delovni tok za izgubljeno napravo obstaja prav zato, da zavrnitev ne postane dovoljenje za obhod preverjanja pristnosti, in odjemalec bi moral povezati na dokumentiran postopek organizacije, namesto da bi si izmislil svojega.

Pravilo, na katerem je treba graditi, je, da je zavrnitev rezultat, ne ovira. Sporočite jo enkrat, jasno, z dovolj konteksta za ukrepanje, in pustite, da je naslednji poskus nov. Smernice CISA o MFA, odporni na phishing, pojasnjujejo, zakaj je vzorec »sprašuj, dokler ni odobreno« nevaren že od začetka, in to je vir, ki ga je vredno navesti, ko kdo predlaga zanko ponovnih poskusov. Vse, kar odjemalec doda po zavrnitvi, bi moralo človeku olajšati naslednjo odločitev, ne pa mu je odvzeti.