Žiadosť o MFA pre VPN zamietnutá: čo má klient urobiť

Zamietnutá žiadosť o MFA vyzerá ako problém so sieťou, ale nie je. Server požiadal o druhý faktor, faktor sa vrátil negatívne alebo nikdy neprišiel, a relácia bola odmietnutá skôr, než vznikol akýkoľvek tunel. Čo sa stane potom, je otázka správania klienta: ukázať zlyhanie a nechať používateľa začať čistý pokus, alebo opakovať spôsobmi, ktoré generujú ďalšie žiadosti a napokon spustia ochranu účtu. Druhá cesta je to, ako sa z jedného nesprávne napísaného kódu stane uzamknutý účet.

Skontrolujte, ktorá žiadosť zlyhala

Začnite tým, že zistíte, ktorá žiadosť zlyhala. Push oznámenie, kód TOTP, tvrdenie FIDO a tok SAML zlyhávajú každý inak a klient zvyčajne vie, ktorú z nich požiadal. Odmietnutie, vypršaná výzva a zlyhanie doručenia, ktoré sa k zariadeniu nikdy nedostalo, končia všetky rovnakou všeobecnou chybou, takže stav samotného klienta je často jediné miesto, kde rozdiel prežije.

Tento stav sa oplatí zaznamenať presne. Zaznamenajte identifikátor výzvy alebo referenciu transakcie, typ faktora, časovú pečiatku a výsledok, ale nikdy kód ani tvrdenie. Identifikátor výzvy je to, čo administrátorovi umožní nájsť udalosť na strane poskytovateľa identity; bez neho rozhovor s podporou začína slovami „niekedy v poslednej hodine“ a zvyčajne tam aj končí. Berte ho ako diagnostické metadáta, nie ako tajomstvo.

Skúste to raz, zámerne, s novou výzvou

Opakovaný pokus má byť nový pokus s novou výzvou, nie prehratie starej. Keď klient znova použije predchádzajúcu výzvu, poskytovateľ identity ju buď odmietne ako zastaranú, alebo, čo je horšie, prijme schválenie určené pre predchádzajúci pokus. Vyžiadajte si novú výzvu, zobrazte ju a nechajte používateľa konať podľa tej, ktorá je práve na obrazovke.

Dva pokusy s krátkou pauzou medzi nimi sú rozumné predvolené nastavenie; neobmedzená slučka nie je. Ak druhý pokus zlyhá rovnako, zastavte sa a nahláste to namiesto pokračovania.

Čo klient nesmie robiť

Klient nesmie robiť niekoľko vecí, ktoré vyzerajú užitočne a nie sú. Nesmie ďalej posielať push oznámenia, kým niekto neklepne na „schváliť“, pretože to učí používateľov schvaľovať žiadosti, ktoré sami nezačali, a presne na toto správanie sa spoliehajú phishingové sady. Nesmie prejsť na slabší faktor preto, že silný zlyhal, a nesmie vypnúť kontrolu identity servera, aby obišiel sťažnosť na certifikát, ktorá sa objavila v rovnakom čase. Každá z týchto troch skratiek mení zlyhanie autentifikácie na bezpečnostný incident.

Tiež nesmie zlyhanie potichu prehltnúť. Klient, ktorý zavrie spojenie a zobrazí spinner, necháva používateľa bez tušenia, či skúsiť znova, počkať alebo zavolať podpore. Ukážte zlyhanie s typom faktora a krátkym kódom, udržte správu bez tajomstiev a urobte akciu opakovania explicitnou, nie automatickou.

Ak žiadosť nezačal človek pri klávesnici, správna akcia je nechať ju zamietnutú a nahlásiť ju overenou cestou podpory. Schváliť žiadosť, aby prestal hluk, je vzorec zlyhania, nie oprava.

Čo zaznamenať pre podporu

Pre podporu je užitočný záznam malý. Približný čas s časovým pásmom, účet, klient a verzia, typ faktora a neverejný stav každého pokusu: vyžiadané, zamietnuté, vypršané, schválené, ale odmietnuté politikou.

Majte na očiach aj hodiny klienta a servera. TOTP je kontrola časového okna, takže zariadenie s posunutými hodinami vytvára kódy, ktoré vyzerajú platne a zakaždým zlyhajú, a klient, ktorý nahlási neplatný kód bez zmienky o posune, posiela ľudí resetovať prihlasovacie údaje, ktoré nikdy neboli nesprávne. Používateľ, ktorému prihlásenie opakovane zlyháva, by mal pred vytvorením ďalších žiadostí skontrolovať podporovanú verziu klienta, stav registrácie a dokumentovaný postup obnovy.

Cesta obnovy si zaslúži rovnakú starostlivosť ako cesta prihlásenia. Postup pre stratené zariadenie existuje práve preto, aby sa z odmietnutia nestalo povolenie obísť autentifikáciu, a klient by mal odkazovať na dokumentovaný proces organizácie, namiesto toho, aby vymýšľal vlastný.

Pravidlo, proti ktorému treba stavať, je, že odmietnutie je výsledok, nie prekážka. Nahláste ho raz, jasne, s dostatkom kontextu na konanie, a nechajte ďalší pokus byť nový. Pokyny CISA k MFA odolnému voči phishingu vysvetľujú, prečo je vzorec „pýtaj sa, kým sa neschváli“ nebezpečný od začiatku, a je to referencia, ktorú stojí za to citovať, keď niekto navrhne slučku opakovania. Všetko, čo klient po odmietnutí pridá, má uľahčiť človeku ďalšie rozhodnutie, nie mu ho vziať.