MFA zahtjev za VPN odbijen: šta klijent treba da uradi

Odbijen MFA zahtjev izgleda kao mrežni problem, ali nije. Server je tražio drugi faktor, faktor se vratio negativan ili nikada nije stigao, i sesija je odbijena prije nego što je ikakav tunel postojao. Ono što slijedi je pitanje ponašanja klijenta: pokazati neuspjeh i pustiti korisnika da započne čist pokušaj, ili ponavljati na načine koji stvaraju još zahtjeva i na kraju aktiviraju zaštitu računa. Drugi put je način na koji jedan pogrešno otkucan kod postaje zaključan račun.

Provjerite koji zahtjev nije uspio

Počnite utvrđivanjem koji zahtjev nije uspio. Push obavijest, TOTP kod, FIDO tvrdnja i SAML tok ne uspijevaju svaki na svoj način, a klijent obično zna koji je tražio. Odbijanje, istekli izazov i neuspjela dostava koja nikada nije stigla do uređaja svi završavaju istom generičkom greškom, pa je stanje samog klijenta često jedino mjesto gdje razlika preživi.

To stanje vrijedi precizno zabilježiti. Zabilježite identifikator izazova ili referencu transakcije, tip faktora, vremensku oznaku i ishod, ali nikada kod ni tvrdnju. Identifikator izazova je ono što administratoru omogućava da pronađe događaj na strani davatelja identiteta; bez njega razgovor s podrškom počinje s „negdje u posljednjem satu“ i obično tu završava. Tretirajte ga kao dijagnostičke metapodatke, a ne kao tajnu.

Pokušajte ponovo jednom, namjerno, s novim izazovom

Ponovni pokušaj treba biti novi pokušaj s novim izazovom, a ne reprodukcija starog. Kada klijent ponovno upotrijebi prethodni izazov, davatelj identiteta ga ili odbije kao zastario ili, što je gore, prihvati odobrenje namijenjeno ranijem pokušaju. Zatražite svjež izazov, prikažite ga i pustite korisnika da djeluje na onom koji je trenutno na ekranu.

Dva pokušaja s kratkom pauzom između njih razuman su standard; neograničena petlja nije. Ako drugi pokušaj ne uspije na isti način, zaustavite se i izvijestite umjesto da nastavite.

Šta klijent ne smije raditi

Klijent ne smije raditi nekoliko stvari koje izgledaju korisno, a nisu. Ne smije nastaviti slati push obavijesti dok neko ne pritisne „odobri“, jer to uči korisnike da odobravaju zahtjeve koje nisu pokrenuli, i to je upravo ponašanje na koje se oslanjaju phishing kompleti. Ne smije se vratiti na slabiji faktor jer je jaki zakazao, i ne smije isključiti provjeru identiteta servera da bi zaobišao pritužbu na certifikat koja se pojavila u isto vrijeme. Svaki od ta tri prečica pretvara neuspjeh provjere identiteta u sigurnosni incident.

Također ne smije tiho progutati neuspjeh. Klijent koji zatvori vezu i prikaže spinner ostavlja korisnika bez ikakve ideje treba li ponoviti, čekati ili nazvati podršku. Prikažite neuspjeh s tipom faktora i kratkim kodom, držite poruku bez tajni i učinite radnju ponovnog pokušaja eksplicitnom, a ne automatskom.

Ako zahtjev nije pokrenula osoba za tastaturom, ispravna radnja je ostaviti ga odbijenim i prijaviti ga provjerenim putem podrške. Odobravanje zahtjeva da bi se zaustavila buka je obrazac neuspjeha, a ne rješenje.

Šta zabilježiti za podršku

Za podršku je koristan zapis mali. Približno vrijeme s vremenskom zonom, račun, klijent i verzija, tip faktora i nejavni status svakog pokušaja: zatražen, odbijen, istekao, odobren ali odbijen politikom.

Držite na oku i satove klijenta i servera. TOTP je provjera vremenskog okvira, pa uređaj čiji je sat odstupio proizvodi kodove koji izgledaju valjano i ne uspijevaju svaki put, a klijent koji prijavi nevaljan kod bez napomene o odstupanju šalje ljude da resetiraju vjerodajnice koje nikada nisu bile pogrešne. Korisnik čija prijava ne uspijeva iznova treba provjeriti podržanu verziju klijenta, stanje upisa i dokumentirani tok oporavka prije nego što stvori još zahtjeva.

Put oporavka zaslužuje istu pažnju kao put prijave. Tok za izgubljeni uređaj postoji upravo zato da odbijanje ne postane dopuštenje za zaobilaženje provjere identiteta, i klijent treba povezati dokumentirani proces organizacije umjesto da izmišlja vlastiti.

Pravilo prema kojem treba graditi jest da je odbijanje rezultat, a ne prepreka. Prijavite ga jednom, jasno, s dovoljno konteksta za djelovanje, i pustite da sljedeći pokušaj bude nov. CISA-ine smjernice o MFA otpornoj na phishing objašnjavaju zašto je obrazac „pitaj dok se ne odobri“ opasan od početka, i to je referenca koju vrijedi citirati kada neko predloži petlju ponovnih pokušaja. Sve što klijent doda nakon odbijanja treba sljedeću odluku učiniti lakšom za čovjeka, a ne oduzeti mu odluku.