MFA-anmodning til VPN afvist: hvad klienten bør gøre

En afvist MFA-anmodning ligner et netværksproblem og er det ikke. Serveren bad om en anden faktor, faktoren kom negativt tilbage eller kom aldrig, og sessionen blev afvist, før der overhovedet fandtes en tunnel. Hvad der sker bagefter, er et spørgsmål om klientadfærd: vis fejlen, og lad brugeren starte et rent forsøg, eller prøv igen på måder, der skaber flere anmodninger og til sidst udløser kontobeskyttelsen. Den anden vej er, hvordan én forkert indtastet kode bliver en låst konto.

Kontrollér hvilken anmodning der fejlede

Begynd med at identificere, hvilken anmodning der fejlede. En push-meddelelse, en TOTP-kode, en FIDO-erklæring og et SAML-forløb fejler hver på deres måde, og klienten ved normalt, hvilken den bad om. En afvisning, en udløbet udfordring og en leveringsfejl, der aldrig nåede enheden, ender alle i den samme generiske fejl, så klientens egen tilstand er ofte det eneste sted, forskellen overlever.

Den tilstand er værd at logge præcist. Registrér udfordringens id eller transaktionsreference, faktortypen, tidsstemplet og resultatet, men aldrig koden eller erklæringen. Udfordringens id er det, der lader en administrator finde hændelsen på identitetsudbyderens side; uden det begynder supportssamtalen med „et sted i den sidste time“ og slutter normalt der. Behandl det som diagnostiske metadata, ikke som en hemmelighed.

Prøv igen én gang, bevidst, med en ny udfordring

Et nyt forsøg bør være et nyt forsøg med en ny udfordring, ikke en genafspilning af den gamle. Når klienten genbruger den forrige udfordring, afviser identitetsudbyderen den enten som forældet eller, værre, accepterer en godkendelse, der var beregnet til det tidligere forsøg. Anmod om en frisk udfordring, vis den, og lad brugeren handle på den, der er på skærmen lige nu.

To forsøg med en kort pause imellem er et rimeligt standardvalg; en ubegrænset løkke er ikke. Hvis det andet forsøg fejler på samme måde, så stop og rapportér i stedet for at fortsætte.

Hvad klienten ikke må gøre

Klienten må ikke gøre flere ting, der ser hjælpsomme ud og ikke er det. Den må ikke blive ved med at sende push-meddelelser, indtil nogen trykker godkend, for det træner brugere til at godkende anmodninger, de ikke selv startede, og det er præcis den adfærd, phishing-kits regner med. Den må ikke falde tilbage til en svagere faktor, fordi den stærke fejlede, og den må ikke slå serveridentitetskontrollen fra for at komme uden om en certifikatklage, der dukkede op samtidig. Hver af de tre genveje gør et autentificeringssvigt til en sikkerhedshændelse.

Den må heller ikke sluge fejlen i stilhed. En klient, der lukker forbindelsen og viser en spinner, efterlader brugeren uden nogen idé om, hvorvidt de skal prøve igen, vente eller ringe til support. Vis fejlen med faktortypen og en kort kode, hold meddelelsen fri for hemmeligheder, og gør gentagelseshandlingen eksplicit i stedet for automatisk.

Hvis anmodningen ikke blev startet af personen ved tastaturet, er den rigtige handling at lade den være afvist og rapportere den gennem den verificerede supportvej. At godkende en anmodning for at stoppe støjen er fejlmønsteret, ikke løsningen.

Hvad der skal registreres til support

For support er den nyttige registrering lille. Det omtrentlige tidspunkt med tidszonen, kontoen, klienten og versionen, faktortypen og den ikke-hemmelige status for hvert forsøg: anmodet, afvist, udløbet, godkendt men afvist af politik.

Hold også øje med klientens og serverens ure. TOTP er en tidsvindueskontrol, så en enhed med et forskubbet ur producerer gyldigt udseende koder, der fejler hver gang, og en klient, der rapporterer en ugyldig kode uden at nævne forskydningen, sender folk til at nulstille legitimationsoplysninger, der aldrig var forkerte. En bruger, hvis login fejler gentagne gange, bør kontrollere den understøttede klientversion, tilmeldingsstatus og det dokumenterede gendannelsesforløb, før de skaber flere anmodninger.

Gendannelsesvejen fortjener samme omhu som loginvejen. Et forløb for mistet enhed findes netop for, at en afvisning ikke bliver til tilladelse til at omgå autentificering, og en klient bør linke til organisationens dokumenterede proces i stedet for at opfinde sin egen.

Reglen, man skal bygge efter, er, at afvisning er et resultat, ikke en forhindring. Rapportér den én gang, klart, med nok kontekst til at handle på, og lad det næste forsøg være et nyt. CISA’s vejledning om phishing-resistent MFA forklarer, hvorfor mønsteret med at spørge, indtil nogen godkender, er farligt fra starten, og det er den reference, der er værd at citere, når nogen foreslår en gentagelsesløkke. Alt, hvad klienten tilføjer efter en afvisning, bør gøre den næste beslutning lettere for et menneske, ikke fjerne beslutningen fra dem.