MFA-førespurnad til VPN avvist: kva klienten bør gjere

Ein avvist MFA-førespurnad ser ut som eit nettverksproblem og er det ikkje. Tenaren bad om ein andre faktor, faktoren kom negativt tilbake eller kom aldri, og økta vart avvist før det fanst nokon tunnel. Det som skjer vidare, er eit spørsmål om klientåtferd: vise feilen og la brukaren starte eit reint forsøk, eller prøve på nytt på måtar som skaper fleire førespurnader og til slutt utløyser kontobeskyttelsen. Den andre vegen er korleis éin feilskriven kode blir ein låst konto.

Sjekk kva førespurnad som mislykkast

Byrj med å identifisere kva førespurnad som mislykkast. Eit push-varsel, ein TOTP-kode, ein FIDO-påstand og ein SAML-flyt mislykkast kvar på sin måte, og klienten veit vanlegvis kva han bad om. Ei avvising, ei utløpt utfordring og ein leveringsfeil som aldri nådde eininga endar alle i den same generiske feilen, så tilstanden til klienten sjølv er ofte det einaste staden der skilnaden overlever.

Den tilstanden er verdt å logge presist. Registrer id-en til utfordringa eller transaksjonsreferansen, faktortypen, tidsstempelet og resultatet, men aldri koden eller påstanden. Id-en til utfordringa er det som lèt ein administrator finne hendinga hos identitetsleverandøren; utan han byrjar støttesamtalen med «ein stad i løpet av den siste timen» og sluttar vanlegvis der. Handsame det som diagnostiske metadata, ikkje som ein hemmelegheit.

Prøv på nytt éin gong, medvite, med ei ny utfordring

Eit nytt forsøk bør vere eit nytt forsøk med ei ny utfordring, ikkje ei avspeling av den gamle. Når klienten brukar den førre utfordringa om att, avviser identitetsleverandøren ho anten som utdatert eller, verre, godtek ei godkjenning som var meint for det tidlegare forsøket. Be om ei fersk utfordring, vis ho, og la brukaren handle på den som er på skjermen akkurat no.

To forsøk med ei kort pause mellom er eit rimeleg standardval; ei ubegrensa løkke er det ikkje. Viss det andre forsøket mislykkast på same måte, stopp og rapporter i staden for å halde fram.

Kva klienten ikkje må gjere

Klienten må ikkje gjere fleire ting som ser hjelpsame ut og ikkje er det. Han må ikkje halde fram med å sende push-varsel til nokon trykkjer godkjenn, for det trenar brukarar til å godkjenne førespurnader dei ikkje starta, og det er nettopp åtferda phishing-sett reknar med. Han må ikkje falle tilbake til ein svakare faktor fordi den sterke feila, og han må ikkje slå av tenaridentitetskontrollen for å kome forbi ei sertifikatklage som dukka opp samtidig. Kvar av dei tre snarvegane gjer ein autentiseringsfeil om til ei tryggingshending.

Han må heller ikkje svelgje feilen i stillheit. Ein klient som lukkar sambandet og viser ein spinner, lèt brukaren stå utan aning om vedkomande skal prøve på nytt, vente eller ringje support. Vis feilen med faktortypen og ein kort kode, hald meldinga fri for hemmelegheiter, og gjer nytt forsøk til ei eksplisitt handling i staden for ei automatisk.

Viss førespurnaden ikkje vart starta av personen ved tastaturet, er rett handling å la han stå avvist og rapportere han gjennom den verifiserte støttevegen. Å godkjenne ein førespurnad for å stoppe støyen er feilmønsteret, ikkje løysinga.

Kva som skal registrerast for support

For support er den nyttige registreringa lita. Omtrentleg tid med tidssona, kontoen, klienten og versjonen, faktortypen og den ikkje-hemmelege statusen for kvart forsøk: førespurt, avvist, utløpt, godkjend men avvist av policy.

Hald også auge med klokkene til klient og tenar. TOTP er ein tidsvindukontroll, så ei eining med forskyvd klokke produserer koder som ser gyldige ut og feilar kvar gong, og ein klient som rapporterer ein ugyldig kode utan å nemne forskyvinga, sender folk til å tilbakestille påloggingsinformasjon som aldri var feil. Ein brukar som mislykkast med innlogginga gjentekne gonger, bør sjekke den støtta klientversjonen, registreringsstatusen og den dokumenterte attopprettingsflyten før vedkomande genererer fleire førespurnader.

Attopprettingsvegen fortener same omhug som innloggingsvegen. Ein arbeidsflyt for tapt eining finst nettopp for at ei avvising ikkje skal bli løyve til å omgå autentisering, og ein klient bør lenkje til den dokumenterte prosessen til organisasjonen i staden for å finne opp sin eigen.

Regelen å byggje mot er at avvising er eit resultat, ikkje ei hindring. Rapporter ho éin gong, tydeleg, med nok kontekst til å handle, og la det neste forsøket vere nytt. Rettleiinga til CISA om phishing-resistent MFA forklarer kvifor mønsteret med å spørje til nokon godkjenner er farleg frå starten, og det er referansen det er verdt å sitere når nokon føreslår ei løkke med nye forsøk. Alt klienten legg til etter ei avvising, bør gjere den neste avgjerda lettare for eit menneske, ikkje fjerne avgjerda frå det.