VPN MFA-kérés elutasítva: mit tegyen a kliens

Az elutasított MFA-kérés hálózati problémának látszik, és nem az. A kiszolgáló második tényezőt kért, a tényező negatívan jött vissza vagy soha nem érkezett meg, és a munkamenet elutasításra került, mielőtt bármilyen alagút létezett volna. Ami ezután történik, az kliensviselkedés kérdése: feltárni a hibát és hagyni, hogy a felhasználó tiszta kísérletet kezdjen, vagy olyan módon ismételni, amely további kéréseket generál és végül bekapcsolja a fiók védelmét. A második út az, amelyen egy elgépelt kód zárolt fiókká válik.

Ellenőrizze, melyik kérés hiúsult meg

Kezdje annak azonosításával, melyik kérés hiúsult meg. A push-értesítés, a TOTP-kód, a FIDO-állítás és egy SAML-folyamat mind másképp hiúsul meg, és a kliens általában tudja, melyiket kérte. Az elutasítás, a lejárt kihívás és a kézbesítési hiba, amely soha nem érte el az eszközt, mind ugyanabban az általános hibában végződik, ezért a különbség gyakran csak magának a kliensnek az állapotában marad fenn.

Érdemes ezt az állapotot pontosan naplózni. Rögzítse a kihívás azonosítóját vagy a tranzakcióhivatkozást, a tényező típusát, az időbélyeget és az eredményt, de soha ne a kódot vagy az állítást. A kihívás azonosítója az, ami lehetővé teszi az adminisztrátor számára, hogy megtalálja az eseményt az identitásszolgáltató oldalán; nélküle a támogatási beszélgetés azzal kezdődik, hogy „valamikor az elmúlt órában”, és általában ott is ér véget. Kezelje diagnosztikai metaadatként, ne titokként.

Próbálja újra egyszer, szándékosan, új kihívással

Az újrapróbálkozás új kísérlet legyen új kihívással, ne a régi újrajátszása. Amikor a kliens újrahasználja az előző kihívást, az identitásszolgáltató vagy elutasítja elavultként, vagy, ami rosszabb, elfogad egy jóváhagyást, amelyet a korábbi kísérlethez szántak. Kérjen friss kihívást, mutassa meg, és hagyja, hogy a felhasználó azzal foglalkozzon, amelyik most a képernyőn van.

Két kísérlet rövid szünettel közöttük ésszerű alapértelmezés; a korlátlan hurok nem az. Ha a második kísérlet ugyanúgy meghiúsul, álljon meg és jelentsen, ahelyett hogy folytatná.

Mit nem tehet a kliens

A kliens nem tehet meg több dolgot, amelyek hasznosnak látszanak, és nem azok. Nem küldheti tovább a push-értesítéseket, amíg valaki rá nem koppint a „jóváhagyás” gombra, mert ez arra tanítja a felhasználókat, hogy olyan kéréseket hagyjanak jóvá, amelyeket nem ők indítottak, és pontosan erre a viselkedésre épülnek az adathalász csomagok. Nem eshet vissza gyengébb tényezőre azért, mert az erős meghiúsult, és nem kapcsolhatja ki a kiszolgáló identitásellenőrzését, hogy átjusson egy tanúsítványpanaszon, amely ugyanakkor jelent meg. Mindhárom rövidítés hitelesítési hibát biztonsági incidenssé változtat.

A hibát sem nyelheti le csendben. Az a kliens, amely bezárja a kapcsolatot és pörgőt mutat, magára hagyja a felhasználót azzal a kérdéssel, hogy újrapróbálkozzon, várjon vagy hívja a támogatást. Tárja fel a hibát a tényező típusával és egy rövid kóddal, tartsa az üzenetet titkoktól mentesen, és tegye az újrapróbálkozás műveletét kifejezetté az automatikus helyett.

Ha a kérést nem a billentyűzetnél ülő személy indította, a helyes művelet az, hogy elutasítva hagyja, és az ellenőrzött támogatási úton jelentse. A kérés jóváhagyása a zaj elhallgattatása érdekében a hiba mintája, nem a megoldás.

Mit rögzítsen a támogatás számára

A támogatás számára a hasznos feljegyzés kicsi. A hozzávetőleges idő az időzónával, a fiók, a kliens és a verzió, a tényező típusa, és minden kísérlet nem titkos állapota: kérve, elutasítva, lejárt, jóváhagyva, de a szabályzat elutasította.

Tartsa szem előtt a kliens és a kiszolgáló óráját is. A TOTP időablak-ellenőrzés, ezért egy elcsúszott órájú eszköz érvényesnek látszó kódokat állít elő, amelyek minden alkalommal meghiúsulnak, és az a kliens, amely az elcsúszás említése nélkül jelent érvénytelen kódot, olyan hitelesítő adatok visszaállításához küldi az embereket, amelyek soha nem voltak hibásak. Annak a felhasználónak, akinek bejelentkezése ismételten meghiúsul, ellenőriznie kell a támogatott kliensverziót, a regisztráció állapotát és a dokumentált helyreállítási folyamatot, mielőtt további kéréseket generál.

A helyreállítási útvonal ugyanolyan gondosságot érdemel, mint a bejelentkezési. Egy elveszett eszközre vonatkozó munkafolyamat pontosan azért létezik, hogy az elutasítás ne váljon a hitelesítés megkerülésének engedélyévé, és a kliensnek a szervezet dokumentált folyamatára kell hivatkoznia, nem sajátot kitalálnia.

A szabály, amelyre építeni kell: az elutasítás eredmény, nem akadály. Jelentse egyszer, világosan, elég kontextussal a cselekvéshez, és hagyja, hogy a következő kísérlet új legyen. A CISA adathalászatnak ellenálló MFA témájú útmutatása elmagyarázza, miért veszélyes a „kérdezzen, amíg jóvá nem hagyják” minta eleve, és ez az a hivatkozás, amelyet érdemes idézni, amikor valaki újrapróbálkozási hurkot javasol. Mindent, amit a kliens az elutasítás után hozzáad, könnyebbé kell tennie a következő döntést az ember számára, nem elvennie tőle a döntést.