SRP unika przesyłania hasła w wymianie logowania; nie czyni skradzionego weryfikatora nieszkodliwym.
Secure Remote Password, czyli SRP, pozwala klientowi i serwerowi uwierzytelniać się przy użyciu hasła bez przesyłania go w normalnej wymianie protokołu. Może ograniczyć ujawnienie hasła serwerowi, który w przeciwnym razie otrzymywałby je podczas logowania.
Nie usuwa wszystkich związanych z hasłem sekretów z serwera. Serwer przechowuje weryfikator, a skradziony weryfikator może umożliwiać odgadywanie hasła offline. To rozróżnienie jest kluczowe przy ocenie twierdzeń o „logowaniu z wiedzą zerową”.
Co zmienia się względem tradycyjnego logowania hasłem?
W tradycyjnym rozwiązaniu klient wysyła hasło przez uwierzytelnione połączenie TLS. Dobrze zaprojektowany serwer porównuje odpowiedni solony skrót hasła, unika zapisywania danych uwierzytelniających w logach i stosuje zabezpieczenia przed odgadywaniem. TLS chroni połączenie; skrót hasła w inny sposób chroni przechowywane dane uwierzytelniające.
SRP zmienia wymianę. Podczas rejestracji system ustanawia sól i materiał weryfikatora. Przy logowaniu obie strony używają świeżych wartości protokołu oraz swoich sekretów, aby ustanowić i potwierdzić wspólny materiał kluczowy. Klient używa hasła, a serwer swojego weryfikatora. Uczciwy klient nie przesyła samego hasła jako danych logowania.
Specyfikacja SRP w RFC 2945 wyjaśnia podstawy protokołu. W późniejszych profilach i implementacjach trzeba sprawdzić dokładne parametry i kontrole komunikatów; nazwanie projektu „SRP” nie dowodzi poprawności każdej decyzji implementacyjnej.
| Pytanie | Tradycyjne logowanie hasłem przez TLS | Poprawnie zaimplementowana wymiana SRP |
|---|---|---|
| Czy serwer aplikacji otrzymuje wpisane hasło przy logowaniu? | Zazwyczaj tak | Nie w ramach wymiany protokołu |
| Jakie wrażliwe dane uwierzytelniające są przechowywane? | Zazwyczaj solony skrót hasła | Sól i weryfikator wyprowadzony z hasła |
| Czy skradziona baza może umożliwiać odgadywanie offline? | Tak, zależnie od przechowywanego materiału | Tak, skradziony materiał weryfikatora SRP może umożliwiać odgadywanie |
| Czy chroni przed rejestratorem klawiszy? | Nie | Nie |
| Czy automatycznie szyfruje historię wiadomości? | Nie | Nie |
Dlaczego skradziony weryfikator nadal ma znaczenie
RFC 5054, sekcja 3.3 wprost omawia skradzione weryfikatory. Wyjaśnia, że weryfikator może umożliwić atakującemu podszywanie się pod serwer i prowadzenie ataków słownikowych w celu odzyskania hasła.
Istotne rozróżnienie polega na tym, że weryfikator nie jest po prostu tokenem logowania klienta wielokrotnego użytku. Nie czyni go to nieszkodliwym. Atakujący może sprawdzać kandydatów na hasło względem skradzionego materiału, zamiast rozwiązywać problem logarytmu dyskretnego dla każdego możliwego sekretu. Słabe lub ponownie używane hasło nadal stanowi poważne ryzyko.
Limity prób online mogą spowalniać ataki na działającą usługę, ale nie kontrolują obliczeń wykonywanych na skradzionej bazie. Ochrona bazy, staranne przetwarzanie haseł i silne, unikalne hasła pozostają ważne.
Przed czym SRP nie chroni
Przejęte urządzenie końcowe: Złośliwe oprogramowanie może przechwycić hasło przed rozpoczęciem protokołu lub później ukraść uwierzytelnioną sesję.
Złośliwa strona logowania: Jeśli sama strona prosząca o hasło jest wroga, może wysłać wpisany tekst gdzie indziej. Aplikacja internetowa nadal potrzebuje godnej zaufania ścieżki dostarczania.
Wszystkie ścieżki odzyskiwania: Procedura e-mailowa, SMS-owa lub wsparcia przyznająca dostęp do konta ma własne wymagania. Słabsza ścieżka awaryjna może podważyć najsilniejszą normalną metodę logowania.
Każdy aktywny atak sieciowy: Znaczenie mają parametry protokołu, walidacja danych wejściowych, wzajemne potwierdzenie i otaczające uwierzytelnione połączenie. Nie zastępuj wymaganych w danym wdrożeniu zabezpieczeń TLS hasłem „hasło nigdy nie jest przesyłane”.
Metadane ani szyfrowanie czatu: Uwierzytelnianie odpowiada na pytanie, czy sesję należy dopuścić. Nie określa, jakie zapisy rozmów istnieją ani kto posiada klucze odszyfrowujące wiadomości.
Jak Livara oddziela logowanie od odzyskiwania tożsamości
Przegląd bezpieczeństwa Livary opisuje uwierzytelnianie SRP oddzielnie od protokołu wiadomości LVR1. Dokumentuje także szyfrowaną kopię tożsamości w wersji 7, chronioną odrębnym losowym 256-bitowym kluczem odzyskiwania.
Kopia jest szyfrowana przed przesłaniem i przywraca tożsamość kryptograficzną, nie historię czatu. Sama znajomość hasła konta nie przywraca tych kluczy szyfrujących. I odwrotnie: stwierdzenie, że wsparcie nie może odtworzyć sekretu szyfrowania, nie dowodzi, że nie mogą istnieć żadne działania zarządzania kontem ani proces zmiany hasła.
Model zagrożeń uwzględnia również przejęcie urządzenia i widoczne metadane komunikacji. SRP nie powinno służyć do nazywania całej usługi usługą „z wiedzą zerową” o każdym aspekcie aktywności użytkownika.
Praktyczna lista kontrolna oceny
Jako użytkownik wybierz unikalne, silne hasło, chroń urządzenie, przechowuj materiał odzyskiwania w odpowiednim oddzielnym miejscu i zrozum, jak unieważnia się sesje. Nie wpisuj sekretu w niezaufanej witrynie tylko dlatego, że deklaruje używanie SRP.
Jako recenzent techniczny poproś o dokładny profil protokołu, sposób przetwarzania hasła na weryfikator, walidację danych wejściowych, obsługę błędów, przebieg rejestracji i projekt resetowania. Analizuj klienta i serwer razem. Uwzględnij testy nieprawidłowych wartości publicznych, powtórzeń i przerwanych sesji, zamiast polegać wyłącznie na udanym teście logowania.
SRP jest użytecznym narzędziem ograniczania ujawnienia hasła podczas uwierzytelniania. Jego wartość jest wyraźniejsza, gdy rzeczywiste korzyści opisuje się obok kradzieży weryfikatora, przejęcia urządzeń i ryzyka odzyskiwania, zamiast przedstawiać je jako koniec problemów bezpieczeństwa haseł.
