Gdzie trafia kod statycznego wyzwania przy logowaniu OpenVPN

Klient pokazuje drugie pole po polu hasła, wpisujesz kod z tokena sprzętowego, a logowanie nadal kończy się błędem uwierzytelniania. To pole istnieje, więc profil o nie poprosił. Czy serwer kiedykolwiek otrzymał wartość w formie, którą rozumie, to inne pytanie i to ono zasługuje na pierwszą odpowiedź.

Zacznij od zachęty, którą twój klient naprawdę pokazuje

Profil może zawierać dyrektywę statycznego wyzwania z łańcuchem zachęty i flagą, która kontroluje, czy odpowiedź jest wyświetlana podczas wpisywania. Zachęta to to, co widzisz w oknie dialogowym; flaga to preferencja wyświetlania tego samego wejścia. Żadne z nich nie mówi serwerowi, jak cokolwiek weryfikować.

Policz pola, które faktycznie dostałeś. Jedno pole na nazwę użytkownika plus jedno zamaskowane pole to zwykłe logowanie hasłem bez żadnego wyzwania. Drugie pole, które pojawia się po haśle z własną etykietą, to klient realizujący interakcję wyzwania.

Jeśli drugie pole nigdy nie pojawia się w używanym kliencie, ten klient może nie realizować interakcji albo realizować ją tylko przez inny interfejs, na przykład interfejs zarządzania. Sprawdzenie klienta kosztuje mniej niż przepisanie profilu, i zwykle właśnie tam naprawdę leży niezgodność.

Co serwer musi już obsługiwać

Profil opisuje, co klient ma zebrać. Nie włącza weryfikacji na serwerze, a serwer bez odpowiedniej integracji uwierzytelniania po prostu otrzyma hasło, którego nie rozpoznaje. Dlatego niektóre wdrożenia pokazują zachętę i odrzucają każdy kod, i dlatego odpowiedź operatora o tym, który mechanizm wykonuje sprawdzenie, jest tą, która ma znaczenie.

Zapytaj operatora, który mechanizm wykonuje sprawdzenie. Może to być wtyczka rozmawiająca z PAM, hak skryptowy walidujący odpowiedź wobec usługi tokenów albo integracja oparta na zarządzaniu, która sama analizuje upchniętą wartość. Każdy z nich oczekuje nieco innego wejścia.

Tu również trzeba skalibrować oczekiwania. Druga zachęta to mechanizm wejścia, a nie dowód, że egzekwowany jest drugi czynnik, bo egzekwowanie odbywa się po stronie serwera i ujawnia się dopiero przy testowaniu błędnego kodu.

Zakodowane pole, które wysyła interfejs zarządzania

Gdy interfejs prowadzi połączenie przez interfejs zarządzania, hasło i odpowiedź na wyzwanie są przed wysłaniem upychane w jednej wartości. Dokumentacja interfejsu zarządzania opisuje format: prefiks, a następnie hasło i odpowiedź jako osobne komponenty Base64.

Base64 to kodowanie, nie ochrona. Nie ukrywa niczego przed kimś, kto potrafi odczytać pole, i nie zamienia kodu jednorazowego w coś wielokrotnego użytku. Upchnięta wartość zasługuje na takie samo traktowanie jak hasło: poza współdzielonymi profilami, poza wierszami poleceń i poza logami diagnostycznymi.

To kodowanie jest też najczęstszym źródłem zamieszania, bo istnieją teraz trzy formy, które wyglądają podobnie i nie są wymienne. Zwykły plik poświadczeń zawiera hasło. Dosłowne sklejenie hasła i kodu zawiera inny ciąg. Upchnięta odpowiedź klienta zarządzania zawiera trzeci. Zanim zmienisz pole tylko dlatego, że błąd zniknął, potwierdź, której z nich oczekuje twoja ścieżka weryfikacji.

Statyczne kontra dynamiczne: inny czas

Statyczne wyzwanie jest znane przed wysłaniem pierwszego poświadczenia, więc klient może o nie poprosić z góry. Dynamiczne wyzwanie przychodzi później, wysyłane przez przepływ uwierzytelniania po tym, jak wymiana już się zaczęła, i wymaga klienta, który poradzi sobie z żądaniem w środku rozmowy.

Obsługa jednego nie daje drugiego. Dyrektywa profilu konfigurująca statyczną zachętę nie realizuje wyzwania inicjowanego przez serwer, a interfejs obsługujący żądania dynamiczne wciąż może nie pokazywać statycznej. Odczytanie, która strona zainicjowała żądanie, to najszybszy sposób, by je rozróżnić.

Praca bez nadzoru to miejsce, w którym staje się to pytaniem o projekt, a nie o interfejs. Zapisany kod nie jest trwałym poświadczeniem startowym, a ponowne połączenie po godzinach będzie wymagało świeżego wejścia, chyba że wdrożenie obsługuje układ tokenów, który operator świadomie włączył.

Testuj zarówno sukces, jak i porażkę, nie tylko okno dialogowe

Wykonaj obie połowy testu. Poprawne poświadczenia z ważną odpowiedzią powinny się udać; poprawne poświadczenia z celowo błędną odpowiedzią powinny zostać odrzucone. Jeśli oba się udadzą, klient zbiera wejście, którego nic nie weryfikuje, a okno dialogowe zostało wzięte za kontrolkę. Ten jeden test wyłapuje więcej wdrożeń niż jakikolwiek przegląd profilu.

Następnie powtórz połączenie po ponownym połączeniu, z kontem, które nie jest zarejestrowane, i przez tego klienta, którego twoi użytkownicy naprawdę używają. Pojawienie się zachęty to zachowanie klienta; odrzucenie błędnego kodu to serwer egzekwujący coś.