SRP nie przesyła hasła w protokole; nie oznacza to usunięcia hasła, odporności na każdy phishing ani nieszkodliwości weryfikatora.
Passkey i SRP to dwa różne sposoby uwierzytelniania. Passkey wykorzystuje parę kluczy i może wyeliminować potrzebę hasła. SRP nadal opiera się na haśle, ale przy poprawnym wykonaniu protokołu nie wysyła samego hasła do serwera, aby udowodnić jego znajomość.
„Logowanie bez przesyłania hasła” nie jest więc tym samym co „logowanie bez posiadania hasła”. Wybór między tymi metodami powinien opierać się na ryzyku phishingu, zarządzaniu poświadczeniami, odzyskiwaniu dostępu i jakości implementacji, a nie na ogólnej etykiecie „zero knowledge”.
Co zmienia passkey?
W uwierzytelnianiu za pomocą passkey usługa przechowuje klucz publiczny, a użytkownik potwierdza logowanie dzięki kontroli nad kluczem prywatnym. Powiązanie poświadczenia z odpowiednią usługą i originem jest ważną częścią odporności tej metody na phishing. Wyjaśnienie FIDO dotyczące passkey.
Nie wszystkie passkey muszą być synchronizowane w chmurze. Niektóre są przypisane do jednego urządzenia lub klucza bezpieczeństwa; inne są przenoszone między urządzeniami za pośrednictwem dostawcy poświadczeń. Model odzyskiwania i ochronę synchronizacji trzeba sprawdzić dla konkretnego dostawcy. Sama „synchronizacja w chmurze” nie pozwala wnioskować, że firma przechowuje klucze w czytelnej postaci.
Bezpieczeństwo sesji po zalogowaniu to odrębna kwestia. Passkey nie neutralizuje automatycznie złośliwego oprogramowania na urządzeniu ani kradzieży ważnej sesji.
Co SRP przekazuje serwerowi?
SRP należy do rodziny wymiany kluczy uwierzytelnianej hasłem. Zamiast samego hasła serwer przechowuje dane takie jak sól i weryfikator, czyli verifier. Wymieniając wiadomości protokołu, obie strony sprawdzają znajomość sekretu i wspólnego klucza.
Weryfikator nie jest jednak nieszkodliwą daną. Sekcja 3.3 RFC 5054 wyraźnie stwierdza, że napastnik, który zdobędzie weryfikator, może przeprowadzić atak słownikowy w celu odgadnięcia hasła. Twierdzenie, że „kradzież bazy danych nie daje żadnej możliwości zgadywania offline”, jest zatem błędne.
Silne hasło, ochrona serwera, odpowiednie parametry, walidacja danych wejściowych i kontrola prób logowania nadal są potrzebne. SRP nie gwarantuje też bezpieczeństwa strony, na której wpisujesz hasło; złośliwy kod może je przechwycić przed wykonaniem protokołu.
Uczciwe porównanie
| Pytanie | Passkey | SRP |
|---|---|---|
| Czy użytkownik zapamiętuje hasło do usługi? | Zwykle nie; wymagana jest kontrola nad poświadczeniem | Tak, metoda polega na znajomości hasła |
| Co usługa przechowuje do logowania? | Klucz publiczny i powiązane informacje | Weryfikator i powiązane parametry |
| Jak uzyskuje się odporność na phishing? | Powiązanie poświadczenia z usługą/originem w projekcie FIDO | Nieprzesyłanie hasła w protokole nie wystarczy, by fałszywy formularz stał się bezpieczny |
| Czy chmura jest konieczna? | Nie; istnieją także opcje powiązane z urządzeniem | Protokół nie wymaga z natury zewnętrznego dostawcy tożsamości, ale potrzebuje usługi uwierzytelniania |
| Jak przebiega odzyskiwanie dostępu? | Zależy od typu poświadczenia i dostawcy | Określa je polityka konta i produktu, a nie nazwa SRP |
Z tej tabeli nie da się stworzyć bezwzględnego rankingu wszystkich implementacji. Słaba procedura odzyskiwania może osłabić zalety silnej metody logowania.
Jaki związek ma logowanie do konta z kluczami czatu?
Uwierzytelnianie informuje usługę, kto ma prawo działać. Klucze szyfrowania wiadomości określają, kto może odszyfrować treść. Produkt może łączyć te dwie rzeczy, ale relacja musi być udokumentowana.
W dokumentacji bezpieczeństwa Livara SRP opisano jako metodę logowania, a pakiet odzyskiwania v7 dla zaszyfrowanej tożsamości omówiono oddzielnie. Ten pakiet przywraca tożsamość, nie historię czatu. Dlatego „hasło logowania jest poprawne” nie oznacza „wszystkie klucze i stare wiadomości wróciły”.
Ten artykuł jest porównaniem koncepcyjnym, a nie praktycznym testem wszystkich metod logowania Livara czy potwierdzeniem dokładnej implementacji określonego RFC w produkcie.
O co pytać przy wyborze?
- Jeśli urządzenie zaginie, jaka jest alternatywna droga logowania i kto ją kontroluje?
- Czy metoda odzyskiwania jest słabsza od głównego logowania?
- Jak można zobaczyć i unieważnić nieznane sesje?
- Czy zmiana metody logowania zmienia klucze wiadomości lub powiązane urządzenia?
- Jakiego konta i jakiej niezależnej ochrony wymaga synchronizacja poświadczeń?
Podsumowanie: Nie nazywaj passkey z natury „niebezpiecznym, bo chmurowym”, a SRP „odpornym na włamania, bo zero knowledge”. Granice każdej metody i polityka odzyskiwania produktu stanowią podstawę wiarygodnego porównania.
