Zacznij od użytkownika, który zmienił telefon
Nową metodę logowania najłatwiej zaprezentować na własnym urządzeniu. Trudniej obsłużyć osobę, która zgubiła telefon, korzysta z komputera w pracy lub nie pamięta, gdzie zapisała klucz dostępu. Dlatego projekt passkeys powinien zaczynać się od całego cyklu konta, nie tylko przycisku „Zaloguj”. Wypisz scenariusze: pierwsza rejestracja, powrót na znanym urządzeniu, drugie urządzenie, utrata dostępu i zakończenie korzystania z usługi.
Dla portalu klienta rozważ przykład osoby logującej się kilka razy w roku. Taki odbiorca może nie pamiętać nazw technologii ani sposobu wcześniejszej rejestracji. Ekran powinien wyjaśniać dostępne działanie językiem zadania. Nie usuwaj pochopnie sprawdzonej ścieżki odzyskiwania tylko dlatego, że nowa demonstracja logowania jest szybsza. Bezpieczna wygoda oznacza również przewidywalny powrót do konta po zmianie sprzętu.
Rozdziel klucz dostępu od biometrii urządzenia
Passkey opiera się na parze kluczy kryptograficznych. Serwis weryfikuje odpowiedź na wyzwanie przy użyciu klucza publicznego, a prywatny pozostaje po stronie uwierzytelniacza. Użytkownik może odblokować operację metodą oferowaną przez urządzenie, na przykład PIN-em lub biometrią. Nie oznacza to, że strona otrzymuje odcisk palca. W interfejsie warto wyjaśnić to krótko, bez obiecywania identycznego zachowania na każdym systemie.
WebAuthn wiąże poświadczenie z odpowiednim zakresem serwisu. To ważna różnica względem hasła wpisywanego w dowolne pole. Nie należy jednak opisywać tej metody jako usuwającej wszystkie ryzyka przejęcia konta. Nadal istnieją sesje, uprawnienia, urządzenia i procedury odzyskiwania. Sam poprawny ekran logowania nie ochroni portalu, w którym po zalogowaniu można odczytać cudze dokumenty przez zmianę identyfikatora.
Rejestracja kolejnego klucza jest operacją wrażliwą
Dodanie nowego sposobu logowania powinno wymagać odpowiednio mocnego potwierdzenia. Osoba korzystająca z pozostawionej otwartej sesji nie może bez przeszkód ustanowić własnego trwałego dostępu. Zaprojektuj ekran zarządzania kluczami: zrozumiałe nazwy, datę dodania i możliwość usunięcia. Unikaj nadmiernie szczegółowych informacji o urządzeniu, których system nie potrafi wiarygodnie ustalić. Nazwa nadana przez użytkownika może być bardziej użyteczna niż techniczny ciąg znaków.
Dla przykładowego klienta zestaw „telefon prywatny” oraz „klucz zapasowy” jest czytelniejszy niż dwie identyczne pozycje bez opisu. Zanim pozwolisz usunąć ostatnią metodę dostępu, pokaż konsekwencję i sprawdź dostępny sposób powrotu. Ustal także, czy usunięcie klucza kończy już aktywne sesje. Te decyzje nie powinny być przypadkowym skutkiem implementacji, bo wpływają na to, czy odbiorca rzeczywiście odzyska kontrolę po utracie urządzenia.
Odzyskiwanie nie może być słabszym bocznym wejściem
Jeśli zwykłe logowanie ma silną ochronę, a odzyskiwanie polega na podaniu publicznie znanej informacji, bezpieczeństwo całego konta pozostaje słabe. Dobierz procedurę do wartości chronionych danych. W jednym portalu wystarczy dobrze przygotowana metoda zapasowa, w innym potrzebna będzie kontrolowana obsługa przez człowieka. Nie buduj własnych pytań bezpieczeństwa z nazwiska, daty urodzenia czy nazwy firmy, które łatwo poznać poza serwisem.
Opisz, co użytkownik może zrobić sam i kiedy sprawa trafia do obsługi. Pracownik powinien mieć procedurę, a nie możliwość uznaniowego wyłączenia ochrony po przekonującej rozmowie. Komunikaty nie powinny nadmiernie ujawniać, czy dany adres ma konto. Przewidź limit prób oraz rejestrowanie ważnych zmian. Testuj też sytuację osoby mającej dostęp do poczty, ale nie do klucza, oraz odwrotną: dostępny klucz i utracona stara skrzynka.
Wdrażaj metodę bez wymuszania jednego ekosystemu
Nie zakładaj, że każdy klient używa tej samej przeglądarki, menedżera poświadczeń i telefonu. Wykrywaj dostępność potrzebnych funkcji oraz przygotuj czytelną alternatywę. Przerwanie systemowego okna wyboru klucza nie musi oznaczać błędu konta. Użytkownik mógł po prostu zdecydować się na inną metodę. Zamiast alarmującego komunikatu pozwól mu wrócić do wyboru bez powtarzania całej rejestracji.
Na początku warto zaproponować dodanie passkey po poprawnym zalogowaniu dotychczasową metodą. Mierz zakończone rejestracje, udane logowania i przypadki przejścia do pomocy, nie samą liczbę kliknięć przycisku. Osobno obserwuj nowe i powracające urządzenia. Każda zmiana adresu domeny lub struktury logowania wymaga analizy zakresu poświadczeń. Nie traktuj przebudowy subdomen jako wyłącznie kosmetycznej zmiany linków.
Odbierz kompletną ścieżkę, a nie sam protokół
Zestaw testów powinien obejmować poprawne i wygasłe wyzwanie, ponowne użycie odpowiedzi, błędny zakres serwisu, odmowę użytkownika oraz usunięcie klucza. Weryfikacja kryptograficzna należy do serwera i sprawdzonej implementacji, nie do samego skryptu w przeglądarce. Używaj aktualnych bibliotek i testuj integrację z rzeczywistymi uwierzytelniaczami. Makieta z zielonym potwierdzeniem nie daje dowodu, że druga strona poprawnie zweryfikowała operację.
Osobno odbierz teksty pomocy: czy klient wie, co zapisał, gdzie może zarządzać dostępem i co zrobić po zmianie urządzenia? Przygotuj krótką instrukcję dla obsługi, w tym działania zabronione. Dobry projekt passkeys skraca rutynowe logowanie, ale nie ukrywa trudnych przypadków. Najważniejszym rezultatem jest konto, do którego właściwy użytkownik potrafi bezpiecznie wrócić, a osoba nieuprawniona nie uzyska dostępu przez uproszczoną procedurę awaryjną.