Passkey to poświadczenie logowania oparte na kryptografii klucza publicznego, zdefiniowane w standardach WebAuthn (W3C) i FIDO2. Zastępuje hasło parą kluczy: prywatny zostaje na urządzeniu użytkownika, publiczny trafia do serwisu. Logowanie potwierdza się biometrią lub PIN-em urządzenia — serwer nigdy nie przechowuje sekretu, który dałoby się wykraść bazą haseł ani wyłudzić phishingiem.
Na skróty
Czego dowiesz się z artykułu:
- Czym są passkeys i jak działa uwierzytelnianie bez hasła oparte na kluczu publicznym
- Jak passkeys wypadają na tle haseł, kodów SMS i aplikacji authenticator (TOTP)
- 6 kroków wdrożenia passkeys w organizacji — od pilotażu po wyłączenie hasła jako opcji
- Jakie są realne ograniczenia i pułapki wdrożenia (utrata urządzenia, brak wsparcia starszych systemów)
- Które duże usługi już obsługują passkeys i od kiedy
Dla kogo ten artykuł:
- Administratorzy IT i zespoły bezpieczeństwa planujący wdrożenie silnego uwierzytelniania
- Kadra zarządzająca oceniająca inwestycję w passwordless w kontekście NIS2
- Osoby odpowiedzialne za onboarding i politykę haseł w organizacji
Czas czytania: 5 minut
Czym są passkeys i jak działa uwierzytelnianie bez hasła
Passkey to tzw. discoverable credential — poświadczenie widoczne i wybieralne przez system operacyjny bez konieczności wpisywania nazwy użytkownika. Mechanizm opiera się na kryptografii asymetrycznej: podczas rejestracji urządzenie generuje parę kluczy, prywatny zostaje zapisany lokalnie (w bezpiecznym module sprzętowym lub w zaszyfrowanym pęku kluczy zsynchronizowanym w chmurze), a publiczny wysyłany jest do serwisu i tam zapisywany. Przy logowaniu serwer wysyła losowe wyzwanie (challenge), a urządzenie podpisuje je kluczem prywatnym po potwierdzeniu tożsamości biometrią (odcisk palca, Face ID) lub kodem PIN urządzenia. Opisuje to standard WebAuthn — specyfikacja W3C rekomendowana od 2019 roku (Poziom 1) i rozszerzona w 2021 roku (Poziom 2) — w połączeniu z protokołem CTAP2, który FIDO Alliance definiuje jako FIDO2.
Kluczowa różnica względem hasła: serwer nigdy nie poznaje ani nie przechowuje żadnego sekretu współdzielonego. Baza danych z passkeys, nawet wykradziona, zawiera wyłącznie klucze publiczne — bezużyteczne bez odpowiadającego im klucza prywatnego, który fizycznie nie opuszcza urządzenia użytkownika lub zaszyfrowanej synchronizacji w ramach jednego ekosystemu. Apple wprowadził wsparcie dla passkeys w iOS 16 i macOS Ventura (2022), Google uczynił je domyślną metodą logowania do kont Google w maju 2023 roku, a Microsoft dodał obsługę passkeys do Windows Hello i Microsoft Entra ID.
Passkeys na tle haseł, SMS OTP i aplikacji authenticator — porównanie
Poniższa tabela porównuje cztery najpopularniejsze metody uwierzytelniania pod kątem odporności na phishing i typowego progu wejścia.
| Metoda | Odporność na phishing | Wymaga pamiętania sekretu | Typowy próg wejścia |
|---|---|---|---|
| Hasło | Niska — sekret można wyłudzić stroną-klonem | Tak | Brak (natywne wsparcie wszędzie) |
| SMS OTP | Niska–średnia — podatne na SIM swap i przekierowanie kodu na fałszywą stronę | Nie, ale wymaga telefonu z zasięgiem | Niski |
| Aplikacja authenticator (TOTP) | Średnia — kod czasowy nadal można wpisać na fałszywej stronie | Nie | Średni (instalacja i parowanie) |
| Passkey (WebAuthn/FIDO2) | Wysoka z definicji — klucz prywatny podpisuje żądanie związane z konkretną domeną, więc podpis wygenerowany dla fałszywej domeny jest bezużyteczny | Nie | Średni (wymaga urządzenia ze wsparciem biometrii/PIN) |
Regulatorzy podzielają tę ocenę: amerykańskie wytyczne NIST SP 800-63B klasyfikują uwierzytelnianie oparte na FIDO2/WebAuthn jako odporne na phishing z definicji architektury, nie tylko w praktyce. Ma to bezpośrednie przełożenie na liczbę przejętych kont — Microsoft, opierając się na telemetrii własnych usług, wielokrotnie podawał, że włączenie jakiejkolwiek formy uwierzytelniania wieloskładnikowego blokuje ponad 99,9% prób przejęcia konta. Passkeys, odporne na phishing dzięki architekturze, a nie dodatkowemu krokowi, domykają lukę, którą kody SMS i aplikacje TOTP wciąż zostawiają otwartą: możliwość wyłudzenia jednorazowego kodu przez fałszywą stronę logowania.
Wdrożenie passkeys w organizacji w 6 krokach
- Zinwentaryzuj systemy z obsługą WebAuthn/FIDO2 — sprawdź, które aplikacje wewnętrzne i usługi SaaS (dostawca tożsamości, poczta, VPN) już wspierają passkeys jako metodę logowania, zamiast zakładać wsparcie z góry.
- Wybierz dostawcę tożsamości (IdP) jako punkt centralny — wdrożenie passkeys na poziomie Microsoft Entra ID lub innego centralnego IdP jednym ruchem obejmuje wszystkie podpięte aplikacje.
- Uruchom pilotaż na grupie ochotników z zespołu IT — zanim passkeys trafią do całej organizacji, przetestuj scenariusze utraty urządzenia i odzyskiwania dostępu.
- Przygotuj procedurę odzyskiwania dostępu — passkey zsynchronizowany w chmurze (iCloud Keychain, Menedżer haseł Google) przetrwa wymianę telefonu; passkey powiązany wyłącznie ze sprzętowym kluczem bezpieczeństwa wymaga zapasowego klucza lub innej metody odzyskania.
- Utrzymaj hasło jako opcję zapasową podczas przejścia — pełne wyłączenie hasła ma sens dopiero po tym, jak większość użytkowników faktycznie zarejestruje passkey, nie w dniu startu projektu.
- Zmierz adopcję i dopiero wtedy wyłącz starsze metody — SMS OTP i aplikacje TOTP zostają jako fallback do momentu, aż telemetria pokaże, że zdecydowana większość logowań odbywa się już przez passkey.
Ograniczenia i pułapki, o których warto wiedzieć
Passkeys nie są rozwiązaniem bezobsługowym. Trzy praktyczne ograniczenia wracają w każdym wdrożeniu. Po pierwsze, starsze systemy on-premise bez wsparcia WebAuthn (część legacy ERP, część systemów administracji publicznej) nie obsłużą passkeys bez dodatkowej bramki uwierzytelniającej. Po drugie, synchronizacja passkeys między ekosystemami (np. z iCloud Keychain do Menedżera haseł Google) nie zawsze działa automatycznie — użytkownik zmieniający telefon z iPhone’a na Androida może stracić dostęp do zarejestrowanych kluczy, jeśli nie skorzysta ze sprzętowego klucza bezpieczeństwa jako wspólnego mianownika. Po trzecie, passkey powiązany wyłącznie z jednym urządzeniem bez synchronizacji w chmurze to realne ryzyko blokady konta przy zgubieniu sprzętu — dlatego krok 4 powyżej nie jest opcjonalny.
Przeczytaj również
- Cyberbezpieczeństwo: budowanie świadomości w organizacji — poradnik — jak uczyć zespół rozpoznawania phishingu, zanim technologia całkowicie go wyeliminuje
- Architektura Zero Trust: wdrożenie i bezpieczeństwo — jak silne uwierzytelnianie wpisuje się w szerszą architekturę Zero Trust
Rozwiń kompetencje
Temat tego artykułu jest powiązany ze szkoleniem Cyberbezpieczeństwo dla użytkowników. Sprawdź program i zapisz się, aby rozwinąć kompetencje pod okiem ekspertów EITT.
Najczęściej zadawane pytania
Czym różni się passkey od hasła?
Hasło to sekret, który użytkownik pamięta i wpisuje, a serwer przechowuje (zwykle w postaci zahaszowanej) — możliwy do wyłudzenia phishingiem lub wykradzenia z bazy danych. Passkey to para kluczy kryptograficznych: prywatny nigdy nie opuszcza urządzenia, publiczny na serwerze jest bezużyteczny bez niego. Logowanie potwierdza biometria lub PIN urządzenia, nie wpisywanie tekstu.
Czy passkeys można wyłudzić phishingiem?
Nie w taki sam sposób jak hasło czy kod SMS. Podpis kryptograficzny generowany przez passkey jest związany z konkretną domeną usługi — jeśli użytkownik trafi na fałszywą stronę podszywającą się pod prawdziwy serwis, urządzenie po prostu nie znajdzie pasującego passkey do użycia, więc nie ma czego wpisać ani przesłać.
Co się stanie, jeśli zgubię telefon z zapisanymi passkeys?
Zależy od typu passkey. Jeśli był zsynchronizowany w chmurze (iCloud Keychain, Menedżer haseł Google), odzyskujesz dostęp logując się do tego samego ekosystemu na nowym urządzeniu. Jeśli passkey był powiązany wyłącznie z utraconym sprzętem — np. sprzętowy klucz bezpieczeństwa bez kopii zapasowej — potrzebna jest wcześniej przygotowana metoda odzyskania, dlatego procedura odzyskiwania jest częścią każdego poprawnego wdrożenia.
Czy passkeys zastępują uwierzytelnianie wieloskładnikowe (MFA) całkowicie?
W dużej mierze tak — passkey łączy w jednym kroku coś, co masz (urządzenie z kluczem prywatnym) z czymś, czym jesteś lub co wiesz (biometria albo PIN), spełniając definicję uwierzytelniania wieloskładnikowego jednym gestem logowania. Organizacje z podwyższonymi wymogami bezpieczeństwa mogą mimo to łączyć passkeys z dodatkowymi kontrolami na poziomie sesji lub urządzenia.