Twoje hasło VPN jest tak prywatne jak jego weryfikator

Przejdź przez cztery pytania dotyczące każdego logowania VPN: co chroni hasło podczas transmisji, który komponent je otrzymuje, co ten komponent z nim robi i co jest przechowywane później. Każda odpowiedź to inna kontrola, a mocna odpowiedź na jedno nic nie mówi o pozostałych. Błędem jest traktowanie szyfrowania tunelu tak, jakby obejmowało wszystkie cztery. Obejmuje pierwsze i tylko pierwsze.

Pytaj, kto kończy sesję, a nie czy sesja jest szyfrowana.

Szyfrowane względem kogo, dokładnie?

TLS chroni hasło między klientem a tym, co kończy połączenie. Jeśli tym punktem końcowym jest brama VPN, kod uwierzytelniania bramy widzi hasło jawnym tekstem, weryfikuje je i przekazuje dalej je albo wartość pochodną. To zamierzony projekt, nie wyciek. Obserwator sieci na ścieżce nie dowiaduje się niczego użytecznego, a komponent wykonujący weryfikację dowiaduje się wszystkiego, czego potrzebuje.

Społeczność OpenVPN dokumentuje to wyraźnie: auth-user-pass-verify przekazuje przesłane dane logowania skryptowi lub wtyczce weryfikacyjnej. To celowe przekazanie między komponentami i należy do modelu zaufania jako nazwana strona.

Weryfikator widzi hasło

Gdy komponent otrzymuje hasło do weryfikacji, o tym, czy sekret pozostaje zamknięty, decydują jego kontrole dostępu, rejestrowanie i jakość kodu. Skrypt, który zapisuje dane logowania w dzienniku, lub wtyczka, która je buforuje, tworzy znacznie większą ekspozycję niż protokół. Dostęp zależy od architektury i ról, a nie od tunelu, dlatego właściciel usługi kontrolujący weryfikator należy do oceny.

Różne metody ujawniają różny materiał. Uwierzytelnianie certyfikatem dowodzi klucza prywatnego bez jego wysyłania, a przepływ federacyjny może zatrzymać hasło u dostawcy tożsamości, wydając VPN ograniczone stwierdzenie. Te projekty zawężają krąg; żaden z nich nie eliminuje wszystkich zaufanych stron.

Zapisane skróty chronią inny etap

Wytyczne NIST oddzielają chronioną transmisję od odpornego przechowywania weryfikatora. Sól i kosztowny schemat skrótu adresują zagrożenie zapisanym weryfikatorem, czyli to, co dzieje się po fakcie, jeśli baza danych wycieknie. Nie robią nic dla komponentu czasu wykonania, który musi otrzymać dane wejściowe, aby je porównać. Czytanie wytycznych tak, jakby obiecywały tajność w czasie wykonania, jest błędem kategorii.

Dobrze zabezpieczony skrótem magazyn haseł i ujawniony skrypt weryfikacyjny mogą więc współistnieć w jednym produkcie bez sprzeczności.

Wybór metody, która zawęża krąg

Jeśli wymaganiem jest, aby brama nigdy nie otrzymywała hasła wielokrotnego użytku, wybierz metodę, która naprawdę to gwarantuje; zmiana szyfru danych nie tworzy tej właściwości. Weryfikacja certyfikatu serwera VPN mówi, do którego partnera dotarłeś; nie mówi nic o tym, jak ten partner później obchodzi się z danymi logowania. Zachowaj weryfikację serwera, używaj odrębnych danych logowania dla każdej usługi i przestrzegaj obsługiwanego przez organizację przepływu tożsamości.

Zapisz stronę, która otrzymuje hasło, stronę, która je weryfikuje, oraz formę, w jakiej jest przechowywane. Te trzy odpowiedzi należą obok profilu połączenia, ponieważ przeżywają każdy konkretny tunel.

Użyteczne pytanie nie brzmi, czy hasło jest zaszyfrowane, ale przed kim jest ukryte, który komponent je otrzymuje i jaka forma przetrwa później.