MFA-forespørsel til VPN avvist: hva klienten bør gjøre

En avvist MFA-forespørsel ser ut som et nettverksproblem og er det ikke. Serveren ba om en andre faktor, faktoren kom negativt tilbake eller kom aldri, og økten ble avvist før det fantes noen tunnel. Det som skjer videre, er et spørsmål om klientatferd: vise feilen og la brukeren starte et rent forsøk, eller prøve på nytt på måter som skaper flere forespørsler og til slutt utløser kontobeskyttelsen. Den andre veien er hvordan én feilskrevet kode blir en låst konto.

Sjekk hvilken forespørsel som mislyktes

Begynn med å identifisere hvilken forespørsel som mislyktes. Et push-varsel, en TOTP-kode, en FIDO-påstand og en SAML-flyt mislykkes hver på sin måte, og klienten vet vanligvis hvilken den ba om. En avvisning, en utløpt utfordring og en leveringsfeil som aldri nådde enheten ender alle i den samme generiske feilen, så klientens egen tilstand er ofte det eneste stedet der forskjellen overlever.

Den tilstanden er verdt å logge presist. Registrer utfordringens id eller transaksjonsreferansen, faktortypen, tidsstempelet og resultatet, men aldri koden eller påstanden. Utfordringens id er det som lar en administrator finne hendelsen hos identitetsleverandøren; uten den begynner støttesamtalen med «et sted i løpet av den siste timen» og slutter vanligvis der. Behandle det som diagnostiske metadata, ikke som en hemmelighet.

Prøv på nytt én gang, bevisst, med en ny utfordring

Et nytt forsøk bør være et nytt forsøk med en ny utfordring, ikke en avspilling av den gamle. Når klienten gjenbruker den forrige utfordringen, avviser identitetsleverandøren den enten som utdatert eller, verre, godtar en godkjenning som var ment for det tidligere forsøket. Be om en fersk utfordring, vis den, og la brukeren handle på den som er på skjermen akkurat nå.

To forsøk med en kort pause mellom er et rimelig standardvalg; en ubegrenset løkke er det ikke. Hvis det andre forsøket mislykkes på samme måte, stopp og rapporter i stedet for å fortsette.

Hva klienten ikke må gjøre

Klienten må ikke gjøre flere ting som ser hjelpsomme ut og ikke er det. Den må ikke fortsette å sende push-varsler til noen trykker godkjenn, for det trener brukere til å godkjenne forespørsler de ikke startet, og det er nettopp atferden phishing-sett regner med. Den må ikke falle tilbake til en svakere faktor fordi den sterke feilet, og den må ikke slå av serveridentitetskontrollen for å komme forbi en sertifikatklage som dukket opp samtidig. Hver av de tre snarveiene gjør en autentiseringsfeil om til en sikkerhetshendelse.

Den må heller ikke svelge feilen i stillhet. En klient som lukker forbindelsen og viser en spinner, lar brukeren stå uten anelse om vedkommende skal prøve igjen, vente eller ringe support. Vis feilen med faktortypen og en kort kode, hold meldingen fri for hemmeligheter, og gjør nytt forsøk til en eksplisitt handling i stedet for en automatisk.

Hvis forespørselen ikke ble startet av personen ved tastaturet, er riktig handling å la den stå avvist og rapportere den gjennom den verifiserte støtteveien. Å godkjenne en forespørsel for å stoppe støyen er feilmønsteret, ikke løsningen.

Hva som skal registreres for support

For support er den nyttige registreringen liten. Omtrentlig tid med tidssonen, kontoen, klienten og versjonen, faktortypen og den ikke-hemmelige statusen for hvert forsøk: forespurt, avvist, utløpt, godkjent men avvist av policy.

Hold også øye med klokkene til klient og server. TOTP er en tidsvinduskontroll, så en enhet med forskjøvet klokke produserer gyldig utseende koder som feiler hver gang, og en klient som rapporterer en ugyldig kode uten å nevne forskyvningen, sender folk til å tilbakestille påloggingsinformasjon som aldri var feil. En bruker som mislykkes med innloggingen gjentatte ganger, bør sjekke den støttede klientversjonen, registreringsstatusen og den dokumenterte gjenopprettingsflyten før vedkommende genererer flere forespørsler.

Gjenopprettingsveien fortjener samme omhu som innloggingsveien. En arbeidsflyt for tapt enhet finnes nettopp for at en avvisning ikke skal bli tillatelse til å omgå autentisering, og en klient bør lenke til organisasjonens dokumenterte prosess i stedet for å finne opp sin egen.

Regelen å bygge mot er at avvisning er et resultat, ikke en hindring. Rapporter den én gang, tydelig, med nok kontekst til å handle, og la det neste forsøket være nytt. CISAs veiledning om phishing-resistent MFA forklarer hvorfor mønsteret med å spørre til noen godkjenner er farlig fra starten, og det er referansen det er verdt å sitere når noen foreslår en løkke med nye forsøk. Alt klienten legger til etter en avvisning, bør gjøre den neste beslutningen lettere for et menneske, ikke fjerne beslutningen fra det.