MFA-verzoek voor VPN afgewezen: wat de client moet doen

Een afgewezen MFA-verzoek lijkt op een netwerkprobleem en is het niet. De server vroeg om een tweede factor, de factor kwam negatief terug of kwam nooit aan, en de sessie werd geweigerd voordat er überhaupt een tunnel bestond. Wat daarna gebeurt, is een kwestie van clientgedrag: de fout zichtbaar maken en de gebruiker een schone poging laten beginnen, of herhalen op manieren die meer verzoeken opleveren en uiteindelijk de accountbeveiliging activeren. De tweede weg is hoe één verkeerd getypte code een vergrendeld account wordt.

Controleer welk verzoek is mislukt

Begin met vaststellen welk verzoek is mislukt. Een pushmelding, een TOTP-code, een FIDO-assertie en een SAML-stroom falen elk anders, en de client weet meestal welk ervan hij heeft aangevraagd. Een weigering, een verlopen uitdaging en een afleverfout die het apparaat nooit bereikte eindigen allemaal in dezelfde generieke fout, dus de eigen status van de client is vaak de enige plek waar het verschil overleeft.

Die status is het waard om precies te loggen. Leg de uitdagings-id of transactiereferentie, het factortype, de tijdstempel en de uitkomst vast, maar nooit de code of de assertie. De uitdagings-id is wat een beheerder in staat stelt de gebeurtenis aan de kant van de identiteitsprovider te vinden; zonder die id begint het supportgesprek met ‘ergens in het laatste uur’ en eindigt het daar meestal. Behandel het als diagnostische metadata, niet als een geheim.

Probeer het één keer opnieuw, bewust, met een nieuwe uitdaging

Een nieuwe poging moet een nieuwe poging met een nieuwe uitdaging zijn, geen herhaling van de oude. Wanneer de client de vorige uitdaging hergebruikt, weigert de identiteitsprovider die als verouderd of, erger, accepteert een goedkeuring die voor de eerdere poging bedoeld was. Vraag een verse uitdaging aan, toon die en laat de gebruiker handelen op degene die nu op het scherm staat.

Twee pogingen met een korte pauze ertussen is een redelijke standaard; een onbeperkte lus niet. Als de tweede poging op dezelfde manier mislukt, stop en rapporteer in plaats van door te gaan.

Wat de client niet mag doen

De client mag verschillende dingen niet doen die behulpzaam lijken en het niet zijn. Hij mag niet door blijven gaan met pushmeldingen sturen tot iemand op goedkeuren tikt, want dat leert gebruikers verzoeken goed te keuren die ze niet zelf zijn begonnen, en dat is precies het gedrag waarop phishingkits rekenen. Hij mag niet terugvallen op een zwakkere factor omdat de sterke faalde, en hij mag de serveridentiteitscontrole niet uitschakelen om een certificaatklacht te omzeilen die tegelijkertijd opdook. Elk van die drie sluiproutes verandert een authenticatiefout in een beveiligingsincident.

Hij mag de fout ook niet stil inslikken. Een client die de verbinding sluit en een spinner toont, laat de gebruiker zonder enig idee achter of die opnieuw moet proberen, moet wachten of support moet bellen. Toon de fout met het factortype en een korte code, houd de melding vrij van geheimen en maak de actie voor opnieuw proberen expliciet in plaats van automatisch.

Als het verzoek niet is gestart door de persoon achter het toetsenbord, is de juiste actie het afgewezen laten en het melden via het geverifieerde supportpad. Een verzoek goedkeuren om het lawaai te stoppen is het faalpatroon, niet de oplossing.

Wat voor support moet worden vastgelegd

Voor support is het nuttige record klein. De geschatte tijd met de tijdzone, het account, de client en versie, het factortype en de niet-geheime status van elke poging: gevraagd, geweigerd, verlopen, goedgekeurd maar door beleid geweigerd.

Houd ook de klokken van client en server in het oog. TOTP is een controle op een tijdvenster, dus een apparaat waarvan de klok is afgedreven produceert geldig uitziende codes die elke keer falen, en een client die een ongeldige code meldt zonder de afwijking te noemen, stuurt mensen om inloggegevens te resetten die nooit fout waren. Een gebruiker wiens login herhaaldelijk mislukt, moet de ondersteunde clientversie, de inschrijfstatus en de gedocumenteerde herstelstroom controleren voordat hij meer verzoeken genereert.

Het herstelpad verdient dezelfde zorg als het loginpad. Een werkstroom voor een verloren apparaat bestaat juist zodat een weigering geen toestemming wordt om authenticatie te omzeilen, en een client zou moeten linken naar het gedocumenteerde proces van de organisatie in plaats van er zelf een te verzinnen.

De regel waarop gebouwd moet worden is dat weigering een resultaat is, geen obstakel. Meld het één keer, duidelijk, met genoeg context om op te treden, en laat de volgende poging een nieuwe zijn. De richtlijnen van CISA over phishingbestendige MFA leggen uit waarom het patroon ‘blijven vragen tot goedkeuring’ vanaf het begin gevaarlijk is, en dat is de referentie die het waard is om te citeren wanneer iemand een herhaallus voorstelt. Alles wat de client na een weigering toevoegt, zou de volgende beslissing voor een mens makkelijker moeten maken, niet de beslissing van hen afnemen.