Żądanie MFA do VPN odrzucone: co powinien zrobić klient

Odrzucone żądanie MFA wygląda jak problem z siecią i nim nie jest. Serwer poprosił o drugi czynnik, czynnik wrócił negatywnie albo nigdy nie dotarł, a sesja została odrzucona, zanim powstał jakikolwiek tunel. To, co dzieje się dalej, jest kwestią zachowania klienta: pokazać błąd i pozwolić użytkownikowi zacząć czystą próbę albo ponawiać w sposób, który generuje kolejne żądania i w końcu uruchamia ochronę konta. Druga droga to sposób, w jaki jeden błędnie wpisany kod staje się zablokowanym kontem.

Sprawdź, które żądanie nie powiodło się

Zacznij od ustalenia, które żądanie nie powiodło się. Powiadomienie push, kod TOTP, asercja FIDO i przepływ SAML zawodzą każde inaczej, a klient zwykle wie, o które poprosił. Odmowa, wygasłe wyzwanie i błąd dostarczenia, który nigdy nie dotarł do urządzenia, kończą się tym samym ogólnym błędem, więc różnica często przetrwa tylko w stanie samego klienta.

Ten stan warto zapisać precyzyjnie. Zapisz identyfikator wyzwania lub referencję transakcji, typ czynnika, znacznik czasu i wynik, ale nigdy kodu ani asercji. Identyfikator wyzwania pozwala administratorowi znaleźć zdarzenie po stronie dostawcy tożsamości; bez niego rozmowa z pomocą zaczyna się od „gdzieś w ciągu ostatniej godziny” i zwykle tam się kończy. Traktuj go jako metadane diagnostyczne, a nie tajemnicę.

Ponów raz, świadomie, z nowym wyzwaniem

Ponowienie powinno być nową próbą z nowym wyzwaniem, a nie odtworzeniem starego. Gdy klient używa ponownie poprzedniego wyzwania, dostawca tożsamości albo odrzuca je jako nieaktualne, albo, co gorsza, akceptuje zatwierdzenie przeznaczone dla wcześniejszej próby. Poproś o świeże wyzwanie, pokaż je i pozwól użytkownikowi działać na tym, które jest teraz na ekranie.

Dwie próby z krótką przerwą między nimi to rozsądna wartość domyślna; nieograniczona pętla nią nie jest. Jeśli druga próba zawiedzie w ten sam sposób, zatrzymaj się i zgłoś, zamiast kontynuować.

Czego klient nie może robić

Klient nie może robić kilku rzeczy, które wyglądają na pomocne, a takie nie są. Nie może dalej wysyłać powiadomień push, dopóki ktoś nie stuknie „zatwierdź”, ponieważ uczy to użytkowników zatwierdzania żądań, których nie zainicjowali, i dokładnie na tym zachowaniu opierają się zestawy phishingowe. Nie może przejść na słabszy czynnik dlatego, że silny zawiódł, ani wyłączyć weryfikacji tożsamości serwera, aby obejść skargę dotyczącą certyfikatu, która pojawiła się w tym samym czasie. Każde z tych trzech skrótów zamienia błąd uwierzytelniania w incydent bezpieczeństwa.

Nie może też po cichu połknąć błędu. Klient, który zamyka połączenie i pokazuje spinner, zostawia użytkownika bez pojęcia, czy ponowić, poczekać czy zadzwonić do pomocy. Pokazuj błąd z typem czynnika i krótkim kodem, utrzymuj komunikat bez tajemnic i czyń ponowienie działaniem jawnym, a nie automatycznym.

Jeśli żądania nie zainicjowała osoba przy klawiaturze, właściwym działaniem jest pozostawienie go odrzuconym i zgłoszenie przez zweryfikowaną ścieżkę pomocy. Zatwierdzenie żądania, żeby uciszyć hałas, jest wzorcem porażki, a nie rozwiązaniem.

Co zapisać dla pomocy technicznej

Dla pomocy przydatny zapis jest niewielki. Przybliżony czas ze strefą czasową, konto, klient i wersja, typ czynnika oraz nie-tajny status każdej próby: poproszono, odrzucono, wygasło, zatwierdzono, ale odrzucono przez politykę.

Miej też na oku zegary klienta i serwera. TOTP to sprawdzenie okna czasowego, więc urządzenie z przesuniętym zegarem generuje pozornie ważne kody, które za każdym razem zawodzą, a klient, który zgłasza nieprawidłowy kod bez wzmianki o przesunięciu, wysyła ludzi do resetowania poświadczeń, które nigdy nie były błędne. Użytkownik, którego logowanie zawodzi wielokrotnie, powinien sprawdzić obsługiwaną wersję klienta, stan rejestracji i udokumentowany przepływ odzyskiwania, zanim wygeneruje kolejne żądania.

Ścieżka odzyskiwania zasługuje na taką samą troskę jak ścieżka logowania. Proces dla zgubionego urządzenia istnieje właśnie po to, by odmowa nie stała się zgodą na ominięcie uwierzytelniania, a klient powinien linkować do udokumentowanego procesu organizacji, zamiast wymyślać własny.

Zasada, na której trzeba budować, brzmi: odmowa jest wynikiem, nie przeszkodą. Zgłoś ją raz, wyraźnie, z wystarczającym kontekstem do działania, i pozwól, by następna próba była nowa. Wytyczne CISA dotyczące MFA odpornego na phishing wyjaśniają, dlaczego wzorzec „pytaj, aż zatwierdzą” jest niebezpieczny od samego początku, i to jest źródło, które warto cytować, gdy ktoś proponuje pętlę ponowień. Wszystko, co klient dodaje po odmowie, powinno ułatwiać człowiekowi następną decyzję, a nie odbierać mu decyzji.