VPN-MFA-versoek verwerp: wat die kliënt moet doen

’n Verwerpte MFA-oproep lyk soos ’n netwerkprobleem, en is nie een nie. Die bediener het om ’n tweede faktor gevra, die faktor het negatief teruggekom of het nooit aangekom nie, en die sessie is geweier voordat enige tonnel bestaan het. Wat daarna gebeur, is ’n kwessie van kliëntgedrag: maak die fout sigbaar en laat die gebruiker ’n skoon poging begin, of probeer weer op maniere wat meer oproepe skep en uiteindelik die rekeningbeskerming aktiveer. Die tweede pad is hoe een verkeerd getikte kode ’n geslote rekening word.

Kontroleer watter versoek misluk het

Begin deur te bepaal watter versoek misluk het. ’n Pushkennisgewing, ’n TOTP-kode, ’n FIDO-bewering en ’n SAML-vloei misluk elkeen anders, en die kliënt weet gewoonlik watter een hy aangevra het. ’n Weiering, ’n vervalde uitdaging en ’n afleweringsfout wat nooit die toestel bereik het nie, eindig almal in dieselfde generiese fout, so die kliënt se eie toestand is dikwels die enigste plek waar die verskil oorleef.

Daardie toestand is die moeite werd om presies te log. Teken die uitdaging-identifiseerder of transaksieverwysing aan, die faktortipe, die tydstempel en die uitkoms, maar nooit die kode of die bewering nie. ’n Uitdaging-identifiseerder is wat ’n administrateur in staat stel om die gebeurtenis aan die identiteitsverskaffer se kant te vind; sonder dit begin die ondersteuningsgesprek met “iewers in die laaste uur” en eindig gewoonlik daar. Behandel dit as diagnostiese metadata, nie as ’n geheim nie.

Probeer een keer weer, doelbewus, met ’n nuwe uitdaging

’n Herprobeerslag moet ’n nuwe poging met ’n nuwe uitdaging wees, nie ’n herhaling van die ou een nie. Wanneer die kliënt die vorige uitdaging hergebruik, verwerp die identiteitsverskaffer dit as verouderd of, erger, aanvaar ’n goedkeuring wat vir die vroeëre poging bedoel was. Vra ’n vars uitdaging aan, wys dit, en laat die gebruiker op die een reageer wat tans op die skerm is.

Twee pogings met ’n kort pouse tussenin is ’n redelike verstek; ’n onbegrensde lus is nie. As die tweede poging op dieselfde manier misluk, stop en rapporteer eerder as om aan te hou.

Wat die kliënt nie mag doen nie

Die kliënt mag nie verskeie dinge doen wat behulpsaam lyk en nie is nie. Dit mag nie aanhou om pushkennisgewings te stuur totdat iemand op goedkeur tik nie, want dit leer gebruikers om oproepe goed te keur wat hulle nie begin het nie, en dit is presies die gedrag waarop phishing-pakette staatmaak. Dit mag nie terugval na ’n swakker faktor omdat die sterk een gefaal het nie, en dit mag nie die bediener-identiteitskontrole afskakel om verby ’n sertifikaatklag te kom wat terselfdertyd verskyn het nie. Daardie drie kortpaadjies verander elkeen ’n verifikasiemislukking in ’n sekuriteitsinsident.

Dit mag ook nie die mislukking stilweg insluk nie. ’n Kliënt wat die verbinding sluit en ’n spinner wys, laat die gebruiker sonder enige idee of hy moet herprobeer, wag of ondersteuning bel. Wys die mislukking met die faktortipe en ’n kort kode, hou die boodskap vry van geheime, en maak die herprobeer-aksie eksplisiet eerder as outomaties.

As die versoek nie deur die persoon by die sleutelbord begin is nie, is die korrekte aksie om dit verwerp te laat en dit deur die geverifieerde ondersteuningspad te rapporteer. Om ’n oproep goed te keur om die geraas te stop, is die foutmodus, nie die oplossing nie.

Wat om vir ondersteuning aan te teken

Vir ondersteuning is die nuttige rekord klein. Die benaderde tyd met die tydsone, die rekening, die kliënt en weergawe, die faktortipe, en die nie-geheime status van elke poging: gevra, geweier, verstryk, goedgekeur maar deur beleid verwerp.

Hou ook die kliënt- en bediener-horlosies in die oog. TOTP is ’n tydvenster-kontrole, so ’n toestel wie se horlosie gedryf het, produseer geldig-lykende kodes wat elke keer misluk, en ’n kliënt wat ’n ongeldige kode rapporteer sonder om die drywing te noem, stuur mense om geloofsbriewe te herstel wat nooit verkeerd was nie. ’n Gebruiker wie se aanmelding herhaaldelik misluk, moet die ondersteunde kliëntweergawe, die inskrywingstoestand en die gedokumenteerde herstelvloei nagaan voordat hy meer oproepe skep.

Die herstelpad verdien dieselfde sorg as die aanmeldpad. ’n Werkvloei vir verlore toestelle bestaan juis sodat ’n verwerping nie toestemming word om verifikasie te omseil nie, en ’n kliënt moet na die organisasie se gedokumenteerde proses skakel eerder as om een te improviseer.

Die reël om teen te bou, is dat verwerping ’n resultaat is, nie ’n hindernis nie. Rapporteer dit een keer, duidelik, met genoeg konteks om op te tree, en laat die volgende poging ’n nuwe een wees. CISA se leiding oor MFA wat bestand is teen phishing verduidelik waarom die patroon van aanhou vra tot goedkeuring in die eerste plek gevaarlik is, en dit is die verwysing wat die moeite werd is om aan te haal wanneer iemand ’n herprobeer-lus voorstel. Alles wat die kliënt ná ’n verwerping byvoeg, moet die volgende besluit vir ’n mens makliker maak, nie die besluit van hulle wegneem nie.