Passkeys zastępują hasła kryptografią klucza publicznego. Urządzenie uwierzytelniające użytkownika przechowuje klucz prywatny, a usługa internetowa zapisuje klucz publiczny i podczas logowania weryfikuje podpisane żądanie.

Sam mechanizm uwierzytelniania jest prosty. Wdrożenie w dużej organizacji wymaga jednak decyzji dotyczących potwierdzania tożsamości, rejestracji poświadczeń, odzyskiwania dostępu, synchronizowanych passkeys, urządzeń współdzielonych, autoryzacji oraz aplikacji zbudowanych przed powstaniem WebAuthn.

Poniższe pytania zadali uczestnicy webinaru FIDO Alliance „Enterprise Passkeys: What Works, What Doesn’t, and How to Roll Them Out”. Odpowiedzi wykorzystują doświadczenia z wdrożenia w bankowości i odnoszą się do problemów spotykanych w większości organizacji planujących wdrożenie passkeys.

1. Czy jeden passkey może uwierzytelniać użytkownika w różnych domenach?

Passkey jest rejestrowany dla konkretnego identyfikatora Relying Party ID (RP ID), zwykle powiązanego z domeną. Powiązanie z pochodzeniem zapewnia odporność na phishing: poświadczenie utworzone dla jednej strony nie wygeneruje poprawnej odpowiedzi dla innej domeny.

Organizacje najczęściej zapewniają dostęp do wielu usług na 3 sposoby:

• Federacja przez centralnego dostawcę tożsamości. Użytkownik loguje się do IdP za pomocą passkey, a IdP przekazuje tokeny lub asercje do połączonych aplikacji.

• Related Origin Requests. WebAuthn Level 3 pozwala powiązanym domenom korzystać z tego samego poświadczenia przez konfigurację /.well-known/webauthn. Przed wdrożeniem trzeba sprawdzić obsługę tej funkcji w przeglądarkach.

• Osobne poświadczenia dla osobnych stron ufających. Niezależne marki, organizacje i granice bezpieczeństwa zwykle zachowują własne passkeys.

Uwierzytelnianie i autoryzacja pozostają oddzielnymi procesami. Użytkownik może potwierdzić tożsamość raz, a następnie otrzymać dostęp do kilku aplikacji lub podmiotów zgodnie z polityką uprawnień.

2. Czy jeden użytkownik może obsługiwać kilka firm na tej samej platformie?

Tak. Passkey potwierdza tożsamość użytkownika, a polityka aplikacji określa, do których firm, klientów lub jednostek organizacyjnych ma on dostęp.

Jest to szczególnie przydatne w systemach wielodostępnych. Pracownik biura rachunkowego może obsługiwać wiele organizacji przy użyciu jednej tożsamości. Po uwierzytelnieniu system udostępnia mu właściwe zasoby klientów.

Każdy klient może utrzymywać własną politykę uwierzytelniania. Jedna organizacja może już wymagać passkeys, gdy inna nadal korzysta ze starszej metody podczas migracji.

3. Czy można od początku utworzyć konto bez hasła?

Tak. Organizacja może utworzyć konto bez nadawania hasła, jeśli wcześniej wiarygodnie ustali tożsamość użytkownika.

Proces obejmuje 2 oddzielne kroki: weryfikacja tożsamości potwierdza, kim jest użytkownik, a rejestracja poświadczenia wiąże passkey ze zweryfikowanym kontem.

Metoda weryfikacji zależy od ryzyka i obowiązków regulacyjnych. Może obejmować KYC, dokument tożsamości, zaufaną tożsamość cyfrową, weryfikację w placówce, istniejącą relację z klientem albo poświadczenie wydane przez pracodawcę.

Po weryfikacji passkey może stać się podstawową metodą logowania. W czasie migracji obecni klienci mogą dodać passkey po zalogowaniu dotychczasową metodą, a nowi przejść proces rejestracji bezhasłowej od początku.

4. Jak potwierdzać tożsamość przed rejestracją passkey?

Weryfikacja tożsamości powinna poprzedzać rejestrację. Wymagany poziom pewności musi odpowiadać ryzyku konta i operacji.

Obecny klient może potwierdzić dodanie kolejnego uwierzytelniacza zaufanym poświadczeniem. Nowy klient cyfrowy może przejść KYC lub użyć akceptowanej tożsamości elektronicznej. Administrator uprzywilejowany powinien przejść mocniejszą kontrolę, a użytkownik, który utracił wszystkie poświadczenia, może wymagać ponownego potwierdzenia tożsamości.

Warto też wymagać świeżego uwierzytelnienia przed dodaniem passkey. Skradziony plik cookie sesji nie powinien wystarczyć do zapisania trwałego poświadczenia na koncie.

5. Jak zaprojektować odzyskiwanie dostępu?

Proces odzyskiwania często daje atakującym łatwiejszą drogę do konta niż podstawowa metoda logowania. Trzeba zaprojektować go przed wdrożeniem i sprawdzić w pilotażu.

Typowe zabezpieczenia obejmują drugi passkey, dedykowane poświadczenie odzyskiwania, ponowną weryfikację tożsamości, zgodę administratora dla kont uprzywilejowanych, opóźnienie zmian wysokiego ryzyka, niezależne powiadomienie użytkownika, natychmiastowe unieważnienie utraconych poświadczeń oraz pełny zapis audytowy.

Każda droga powrotu do konta powinna zapewniać poziom pewności odpowiadający ryzyku tego konta.

6. Co odejście Microsoftu od SMS i połączeń głosowych oznacza dla projektów passkeys?

Wycofywanie uwierzytelniania przez SMS i połączenia głosowe w Microsoft Entra ID jest dobrym momentem na przegląd miejsc, w których te metody są nadal używane.

Przegląd powinien objąć użytkowników zależnych od SMS lub połączeń, aplikacje bez obsługi uwierzytelniania odpornego na phishing, scenariusze pracowników pierwszej linii i odzyskiwania dostępu oraz systemy starszego typu, które mogą opóźnić migrację.

Etapowe przejście ogranicza zakłócenia. Wiele organizacji najpierw dodaje passkeys obok znanych metod, testuje rejestrację i odzyskiwanie, a dopiero później wycofuje metody podatne na przechwycenie i socjotechnikę.

7. Dlaczego rejestracja passkey wymaga dodatkowej weryfikacji?

Dodanie passkey zmienia zestaw osób i urządzeń, które mogą uzyskać dostęp do konta. Proces rejestracji musi więc potwierdzić, że zmianę zlecił właściciel konta.

Organizacje wymagają zwykle świeżej sesji uwierzytelnionej, kodu TOTP, istniejącego passkey, innej zatwierdzonej metody MFA albo kontroli tożsamości dobranej do ryzyka konta.

Mocniejsza kontrola dotyczy zmiany zestawu poświadczeń. Codzienne logowanie passkey może pozostać szybkie.

8. Czy synchronizowane passkeys są odporne na phishing?

Tak. Synchronizowane i przypisane do urządzenia passkeys korzystają z tego samego powiązania z pochodzeniem w WebAuthn. Strona phishingowa nie uzyska poprawnej odpowiedzi uwierzytelniającej dla prawidłowej domeny.

Synchronizacja dodaje do analizy ryzyka kwestię przechowywania poświadczeń. Zespół bezpieczeństwa powinien ocenić ochronę konta menedżera poświadczeń, sposób dodawania nowych urządzeń, odzyskiwanie dostępu do tego konta oraz skutki jego przejęcia.

Polityka może różnić się między grupami użytkowników. Synchronizowane passkeys ułatwiają klientom zmianę telefonu lub komputera. Administratorzy uprzywilejowani mogą wymagać poświadczeń przypisanych do urządzenia albo sprzętowych kluczy bezpieczeństwa.

9. Jak obsługiwać synchronizowane passkeys na nowych urządzeniach?

Poprawny passkey potwierdza posiadanie poświadczenia. Osobna polityka urządzeń określa, czy organizacja ufa urządzeniu, które go używa.

Gdy passkey pojawia się na nowym urządzeniu przez synchronizację, organizacja może wymagać potwierdzenia istniejącą metodą, zgody z innego zarejestrowanego uwierzytelniacza, rejestracji urządzenia albo dodatkowej oceny ryzyka.

Takie podejście zachowuje korzyści z synchronizacji i odzyskiwania, a jednocześnie daje organizacji kontrolę nad dostępem z urządzeń.

10. Czy ograniczać uwierzytelniacze za pomocą atestacji?

Decyzja zależy od wdrożenia. Atestacja może przekazać informacje o uwierzytelniaczu, który utworzył poświadczenie, na przykład o rodzinie urządzeń lub producencie.

W środowisku pracowniczym atestacja może potwierdzić używanie zatwierdzonego sprzętu lub zarządzanych urządzeń. Usługi konsumenckie muszą obsługiwać szerszy zestaw urządzeń, dlatego krótka lista konkretnych modeli może blokować prawidłowych użytkowników.

Często lepiej definiować politykę według rodziny uwierzytelniaczy, wymagań dotyczących weryfikacji użytkownika, statusu zarządzania urządzeniem lub poziomu pewności. Atestacja może być jednym z elementów decyzji o ryzyku.

11. Dlaczego warto ograniczyć liczbę zarejestrowanych passkeys?

WebAuthn nie określa maksymalnej liczby passkeys dla użytkownika. Limit ustala organizacja zgodnie ze swoim modelem bezpieczeństwa i wsparcia.

Brak limitu może pozostawić na koncie zapomniane telefony, wycofane laptopy i stare klucze bezpieczeństwa. Zbyt niski limit zwiększa liczbę zgłoszeń przy każdej zmianie urządzenia.

Panel konta powinien pokazywać nazwę urządzenia lub poświadczenia, datę rejestracji, datę ostatniego użycia, typ uwierzytelniacza, status synchronizacji oraz opcję samodzielnego usunięcia. Dodanie lub usunięcie passkey powinno wymagać świeżego uwierzytelnienia i wywoływać niezależne powiadomienie.

12. Czy istniejące aplikacje mogą obsługiwać passkeys bez zmian w kodzie?

Tak. Warstwa uwierzytelniania umieszczona przed aplikacją może obsługiwać WebAuthn, integrację z systemem tożsamości i politykę dostępu, gdy aplikacja nadal działa z obecnym kodem.

Taki model pozwala objąć jednym programem aplikacje nowe i starszego typu, zarządzać polityką w jednym miejscu oraz ograniczyć liczbę oddzielnych projektów programistycznych.

Organizacja nadal musi ocenić wszystkie elementy uczestniczące w uwierzytelnianiu: dostawców tożsamości, load balancery i reverse proxy, zarządzanie sesją, logowanie zdarzeń, narzędzia wsparcia, odzyskiwanie oraz metody awaryjne.

Wdrożenie bankowe omawiane podczas webinaru wykorzystało właśnie to podejście. Bank wprowadził passkeys bez zmian w kodzie aplikacji.

13. Jak zabezpieczyć kod uwierzytelniania działający poza aplikacją?

Kod uwierzytelniania wymaga tych samych zabezpieczeń inżynieryjnych co inne elementy systemu produkcyjnego o znaczeniu dla bezpieczeństwa, niezależnie od miejsca jego uruchomienia.

Należy stosować bezpieczny proces tworzenia oprogramowania, przegląd kodu, testy penetracyjne, zarządzanie zależnościami, skanowanie podatności, kontrolę integralności i kontrolowane wdrożenia.

Klucze prywatne, certyfikaty i inne sekrety powinny trafiać do dedykowanego systemu zarządzania sekretami z kontrolą dostępu i logami audytowymi. Każdy komponent uczestniczący w uwierzytelnianiu należy traktować jako część zaufanej bazy systemu.

14. Co powinien zawierać plan wdrożenia passkeys?

Model operacyjny trzeba ustalić przed rejestracją pierwszego użytkownika. Plan powinien opisywać:

• wymagania dotyczące potwierdzania tożsamości i procedur rejestracji;

• odzyskiwanie dostępu oraz akceptowane typy uwierzytelniaczy;

• politykę dla passkeys synchronizowanych i przypisanych do urządzenia;

• logowanie audytowe, zaufanie do urządzeń i procesy administratorów oraz helpdesku;

• integrację starszych aplikacji, metody awaryjne i komunikację z użytkownikami.

Pilotaż powinien objąć reprezentatywne grupy. Pracownicy pierwszej linii, administratorzy, kontraktorzy, klienci i kadra zarządzająca mogą potrzebować innych uwierzytelniaczy oraz odmiennych procesów rejestracji i odzyskiwania.

Technologia, polityka i procesy operacyjne

Kryptografia klucza publicznego zapewnia passkeys silną odporność na phishing. Wdrożenie firmowe wymaga też jasnych zasad weryfikacji tożsamości, rejestracji, odzyskiwania, zaufania do urządzeń, autoryzacji oraz obsługi starszych aplikacji.

Przykład banku pokazuje, że zewnętrzna warstwa uwierzytelniania może dodać passkeys do istniejącej aplikacji bez przepisywania jej kodu. Etapowe wdrożenie daje czas na sprawdzenie polityk i procesów wsparcia z prawdziwymi użytkownikami.

Passkeys działają najlepiej, gdy organizacja traktuje je jako część całego cyklu życia tożsamości: od onboardingu, przez codzienne logowanie i odzyskiwanie dostępu, po unieważnienie poświadczeń.

Źródła

W3C Web Authentication Level 3

W3C Secure Payment Confirmation

FIDO Alliance: Passkeys

Microsoft: Passkeys by default and retirement of SMS and voice authentication