MFA-begäran till VPN avvisad: vad klienten bör göra

En avvisad MFA-begäran ser ut som ett nätverksproblem och är det inte. Servern bad om en andra faktor, faktorn kom tillbaka negativ eller kom aldrig fram, och sessionen avvisades innan någon tunnel fanns. Det som händer sedan är en fråga om klientbeteende: visa felet och låta användaren börja ett rent försök, eller försöka igen på sätt som skapar fler begäranden och till slut utlöser kontoskyddet. Den andra vägen är hur en felaktigt skriven kod blir ett låst konto.

Kontrollera vilken begäran som misslyckades

Börja med att identifiera vilken begäran som misslyckades. En push-avisering, en TOTP-kod, en FIDO-assertion och ett SAML-flöde misslyckas var och en på sitt sätt, och klienten vet vanligtvis vilken den bad om. En avvisning, en utgången utmaning och ett leveransfel som aldrig nådde enheten slutar alla i samma generiska fel, så klientens eget tillstånd är ofta den enda platsen där skillnaden överlever.

Det tillståndet är värt att logga exakt. Registrera utmaningens id eller transaktionsreferensen, faktortypen, tidsstämpeln och resultatet, men aldrig koden eller assertionen. Utmaningens id är det som gör att en administratör kan hitta händelsen hos identitetsleverantören; utan det börjar supportsamtalet med ”någon gång under den senaste timmen” och slutar oftast där. Behandla det som diagnostisk metadata, inte som en hemlighet.

Försök igen en gång, medvetet, med en ny utmaning

Ett nytt försök bör vara ett nytt försök med en ny utmaning, inte en uppspelning av den gamla. När klienten återanvänder den tidigare utmaningen avvisar identitetsleverantören den antingen som inaktuell eller, värre, godkänner en godkännande som var avsedd för det tidigare försöket. Begär en färsk utmaning, visa den och låt användaren agera på den som är på skärmen just nu.

Två försök med en kort paus emellan är ett rimligt standardval; en obegränsad loop är det inte. Om det andra försöket misslyckas på samma sätt, stoppa och rapportera i stället för att fortsätta.

Vad klienten inte får göra

Klienten får inte göra flera saker som ser hjälpsamma ut och inte är det. Den får inte fortsätta skicka push-aviseringar tills någon trycker på godkänn, eftersom det tränar användare att godkänna begäranden de inte själva startat, och det är precis det beteende som phishing-kit räknar med. Den får inte falla tillbaka på en svagare faktor för att den starka misslyckades, och den får inte stänga av serveridentitetskontrollen för att komma förbi ett certifikatklagomål som dök upp samtidigt. Var och en av de tre genvägarna gör ett autentiseringsfel till en säkerhetsincident.

Den får inte heller svälja felet i tysthet. En klient som stänger anslutningen och visar en spinner lämnar användaren utan en aning om ifall den ska försöka igen, vänta eller ringa supporten. Visa felet med faktortypen och en kort kod, håll meddelandet fritt från hemligheter och gör åtgärden för nytt försök explicit i stället för automatisk.

Om begäran inte startades av personen vid tangentbordet är rätt åtgärd att låta den stå avvisad och rapportera den via den verifierade supportvägen. Att godkänna en begäran för att stoppa oljudet är felmodellen, inte lösningen.

Vad som ska registreras för supporten

För supporten är den användbara registreringen liten. Den ungefärliga tiden med tidszonen, kontot, klienten och versionen, faktortypen och den icke-hemliga statusen för varje försök: begärd, avvisad, utgången, godkänd men avvisad av policy.

Håll också koll på klientens och serverns klockor. TOTP är en tidsfönsterkontroll, så en enhet med förskjuten klocka producerar giltigt utseende koder som misslyckas varje gång, och en klient som rapporterar en ogiltig kod utan att nämna förskjutningen skickar folk att återställa inloggningsuppgifter som aldrig var fel. En användare vars inloggning misslyckas upprepade gånger bör kontrollera den supporterade klientversionen, registreringsstatusen och det dokumenterade återställningsflödet innan hen skapar fler begäranden.

Återställningsvägen förtjänar samma omsorg som inloggningsvägen. Ett arbetsflöde för förlorad enhet finns just för att en avvisning inte ska bli tillstånd att kringgå autentisering, och en klient bör länka till organisationens dokumenterade process i stället för att hitta på en egen.

Regeln att bygga mot är att avvisning är ett resultat, inte ett hinder. Rapportera den en gång, tydligt, med tillräckligt sammanhang för att agera, och låt nästa försök vara nytt. CISAs vägledning om phishing-resistent MFA förklarar varför mönstret att fråga tills någon godkänner är farligt från början, och det är referensen som är värd att citera när någon föreslår en loop av nya försök. Allt klienten lägger till efter en avvisning bör göra nästa beslut lättare för en människa, inte ta bort beslutet från hen.