Passkeys to pułapka? Co jest prawdą w najgłośniejszej krytyce kluczy dostępu

W sobotę Hacker News rozgrzał się wokół tematu, który zwykle żyje w niszowych dyskusjach o uwierzytelnianiu. Esej opublikowany dziesiątego października na substacku Non-Functional nosił tytuł „Passkeys are a trap” i zebrał 840 punktów oraz ponad 450 komentarzy. Autor piszący pod pseudonimem The Hack twierdzi, że klucze dostępu są jak koń trojański: eleganckie z zewnątrz, a w środku mechanizm odbierania użytkownikowi kontroli nad własnym kontem. Spór trafił w dobry moment, bo passkeys przestają być ciekawostką. Google i Apple proponują je każdemu nowemu kontu, a od czwartego kwartału Bank Pekao zacznie ich używać do uwierzytelniania płatności internetowych.

Rozbieram zarzuty eseisty na tle specyfikacji i dokumentacji, dodaję kontrę z dyskusji, a na końcu konkrety: kiedy passkey pomaga, kiedy wiąże ręce i co zrobić, żeby nie zamknąć się w cudzym ogrodzeniu.

Spis treści:

Co to jest passkey
Trzy zarzuty eseju
Co się broni, a co nie
Eksport już istnieje, ale to dopiero początek
Polska: klucze wchodzą przez banki
Praktycznie: kiedy passkey, kiedy nie
Nota uczciwości

Co to jest passkey

Passkey, po polsku klucz dostępu, to para kluczy kryptograficznych. Klucz publiczny trafia na serwer serwisu, w którym zakładasz konto. Klucz prywatny zostaje po twojej stronie, choć przy wariantach zsynchronizowanych podróżuje w zaszyfrowanym syncu między twoimi urządzeniami. Serwisowi nigdy go nie pokazujesz. Przy logowaniu strona rzuca wyzwanie kryptograficzne, twoje urządzenie je podpisuje i to cały sekret. Nie ma hasła, które da się podstępnie wyciągnąć, a klucz odpowiada tylko właściwej domenie, więc fałszywa kopia banku nie dostanie podpisu i logowanie po prostu nie przejdzie. Nawet autor eseju przyznaje w dopisku na końcu tekstu, że passkeys są odporne na ataki pośrednie i że sam „naprawdę chce z nich korzystać i polecać je dalej”.

FIDO Alliance, organizacja stojąca za standardem, definiuje passkey szeroko, jako „termin ogólnego przeznaczenia, niezwiązany z żadną konkretną platformą”. W tej jednej definicji mieszczą się dwa różne zwierzęta. Klucz zsynchronizowany wędruje między twoimi urządzeniami przez chmurę dostawcy, na przykład Google albo Apple. Klucz związany z urządzeniem nigdy go nie opuszcza, tak działają fizyczne klucze sprzętowe. W praktyce nie zawsze wiesz, który wariant właśnie utworzyłeś, a od tego zależy, co stanie się, gdy telefon wpadnie do jeziora.

Trzy zarzuty eseju

Pierwszy jest językowy. Pod jedną nazwą kryje się mnóstwo wariantów różniących się tym, gdzie klucz mieszka, czy można go kopiować i co się dzieje po utracie sprzętu. Autor zarzuca FIDO, że celowo nazwała wszystko po równo, żeby użytkownik nie czytał drobnego druku. Za tę tezę oberwało mu się w dyskusji od kilku stron, jeden z komentujących nazwał ją wprost niesprawdzoną teorią spiskową. Zgoda, cudzych intencji nie da się udowodnić. Chaos natomiast jest realny i zna go każdy, kto próbował wytłumaczyć komuś bliskiemu, czemu klucz z iPhone’a nie działa w przeglądarce na komputerze z Windows.

Drugi zarzut jest techniczny i najpoważniejszy. Specyfikacja WebAuthn przewiduje poziomy atestu urządzenia, po angielsku attestation. Domyślnie strona dostaje o twój sprzęt zero informacji, dokumentacja MDN mówi wprost, że wartość „none” jest domyślna. Ale serwis może poprosić o więcej. Na szczycie drabiny stoi opcja „enterprise”, zdefiniowana jako atest, który „może zawierać informacje jednoznacznie identyfikujące” urządzenie, przewidziana dla „kontrolowanych wdrożeń w przedsiębiorstwie”. W ludzkich słowach: atest pozwala serwisowi sprawdzić, że klucz powstał na oryginalnym urządzeniu określonego producenta, i odrzucić wszystko inne. Eseista przewiduje, że ta korporacyjna opcja zeszczupleje do codzienności: serwisy zaczną przyjmować wyłącznie klucze z poświadczonego sprzętu, a Linux, stare telefony i własnoręcznie składane menedżery zostaną za bramą. Precedens ma swoją nazwę. UBlock Origin, bloker reklam używany przez miliony, został wycięty z Chrome wraz z wycofywaniem Manifest V2; Google zaczął wyłączać stare rozszerzenia w marcu 2025, a w połowie lipca użytkownicy pisali już pożegnalne wątki, bo bloker po prostu zniknął. Platforma pokazała, że potrafi.

Trzeci zarzut to zamknięcie w ekosystemie. Klucz utworzony w świecie Apple synchronizował się tylko z urządzeniami Apple i nieprzyzwoite było pytanie o Windows. Proton pisał o tym wiosną 2024 w tekście z wymownym tytułem „Big Tech passkey implementations are a trap”: firmy, zdaniem autorów, „wykorzystały technologię do zamknięcia ludzi we własnych ogrodach zamiast dać wszystkim wspólne rozwiązanie”. Do niedawna nie było też formalnej drogi wyjścia, oficjalne FAQ FIDO o przenoszeniu kluczy między menedżerami haseł milczy i zostawia zakładanie kluczy od zera w każdym serwisie osobno.

Co się broni, a co nie

Zarzut z eseju	Stan według źródeł
Jedna nazwa kryje różne warianty	Chaos realny, zarzut o „celowe mylenie” to teza nieudowodniona
Serwisy zaczną wymagać atestu urządzenia	Na dziś konsumenckie serwisy atestu nie wymagają, domyślnie dostają „none”. Decyzja należy jednak do serwisu, nie do ciebie
Nie da się wyciągnąć klucza z ekosystemu	Było prawdą, od 2025 pęka przez standard eksportu
Bez passkeys nie ma ochrony przed phishingiem	Nieprawda, TOTP i klucze sprzętowe też działają, a odporność passkeys na phishing to atut także w oczach autora eseju

Z dyskusji warta przywołania jest racja komentującego o nicku kccqzy: typowe konsumenckie serwisy nie używają atestu, więc na dziś nie ma pułapki, tyle że „zwykły użytkownik nie ma jak tego sprawdzić i zrozumieć”.

Eksport już istnieje, ale to dopiero początek

Na konferencji WWDC w czerwcu 2025 Apple pokazało import i eksport passkeys oparty na specyfikacji Credential Exchange przygotowanej razem z FIDO Alliance. W koalicji zasiedli obok twórcy 1Password, Bitwardena, Dashlane, NordPass i Okty. Transfer idzie aplikacja do aplikacji, z potwierdzeniem biometrią, bez plików z kluczami na dysku. Bitwarden dokumentuje eksport i import po protokole CXP na iOS 26 i Androidzie 14, z warunkiem, że obie aplikacje wspierają protokół. Google zapowiedział podobną funkcję w swoim menedżerze, bez daty.

Moim zdaniem to zmienia rangę zarzutu o zamknięcie w ekosystemie: z cechy stałej robi się stan przejściowy. Logika ostrzeżenia zostaje natomiast bez zmian. Eseista nie twierdzi, że passkeys nie działają, tylko że kontrola nad nimi powoli przechodzi z twoich rąk na platformę. Eksport daje ci wodę, a atest urządzenia mógłby ją z powrotem odciąć: serwis wymagający poświadczonego sprzętu przyjmie klucz tylko z tego jednego miejsca. Na dziś to przewidywanie, nie fakt.

Jeśli klucze chcesz trzymać we własnym menedżerze haseł, w tym w Bitwardenie, który passkeys zapisuje w sejfie na iOS 17, Androidzie 14 i w rozszerzeniach przeglądarek (dokumentacja nie uzależnia tego od planu premium), pamiętaj, że sprawa Bitwardena komplikuje się właśnie teraz: w buildach ze sklepów wchodzi licencja komercyjna, opisywaliśmy to na początku miesiąca.

Polska: klucze wchodzą przez banki

Dwudziestego czwartego lipca cashless.pl opisał decyzję Pekao. Bank wprowadza klucze dostępu do uwierzytelniania płatności internetowych, mechanizmów 3-D Secure i Click to Pay, z wdrażaniem od czwartego kwartału 2026. Klucz powstaje na urządzeniu klienta, potwierdza go odcisk palca, twarz albo PIN i działa niezależnie od aplikacji bankowej. Biuro prasowe banku argumentowało, że klient „tworzy go samodzielnie na swoim urządzeniu i może go używać przy każdej transakcji”. Wdrożenie jest dobrowolne, kody SMS i e-PIN zostają.

Trzy pytania, które ludzie realnie wpisują w wyszukiwarkę obok kluczy: co gdy zgubię telefon, czy mogę odmówić i jak usunąć passkey. Z pierwszym najważniejsze, więc od niego. Zanim cokolwiek zgubisz, upewnij się, że masz drugą drogę wejścia do konta, drugi klucz trzymany w innym miejscu albo metodę zapasową, którą serwis utrzymuje obok passkeyów. Odmówić można wszędzie tam, gdzie wdrożenie jest opcją, Pekao potwierdza to wprost. Usuwanie klucza to zwykle ekran ustawień bezpieczeństwa danego serwisu albo pozycja w menedżerze haseł. Jak wdrożeniami idą pozostali polscy bankowie, nie wiem. Publicznych ogłoszeń na skalę Pekao nie ma, a zgadywać nie zamierzam.

Praktycznie: kiedy passkey, kiedy nie

Passkey pomaga najbardziej tam, gdzie dziś masz hasło z kodem SMS. Kody SMS da się przechwycić, klucz dostępu przechwycić się nie da, bo nie opuszcza twoich urządzeń i odpowiada tylko właściwej domenie. Najważniejsza z rad płynących z tego researchu brzmi: trzymaj klucze w menedżerze haseł zamiast w chmurze jednego systemu. Masz wtedy wieloplatformowość i eksport, o ile menedżer protokół wspiera, a przy zmianie telefonu nie zaczynasz od zera. Zanim włączysz klucz gdziekolwiek, zajrzyj w ustawienia bezpieczeństwa serwisu i sprawdź dwie rzeczy: czy obok klucza zostaje druga metoda logowania i czy da się dodać klucz zapasowy trzymany gdzie indziej. Konta jedyne w swoim rodzaju, bank, urząd rządowy, poczta, przez którą odzyskujesz wszystko inne, traktuj jak klucze do mieszkania. Nigdy jeden egzemplarz.

Dla nieufnych zostaje TOTP, sześciocyfrowe kody z aplikacji uwierzytelniającej. To otwarty standard z 2011 roku, działa w dowolnej aplikacji na dowolnym systemie i przenosisz się z nim, gdzie chcesz, pełna kontrola bez żadnej platformy w środku. Ten argument padł w dyskusji jako pierwsza odpowiedź na „pułapkę”: skoro masz opcję dającą pełną kontrolę, a wybierasz wygodniejszą, to decyzja, nie spisek.

Nota uczciwości

Nie zakładaliśmy żadnych kont testowych i nie przechodziliśmy wdrożeń na żywych kontach. Tekst to zestawienie eseju, specyfikacji WebAuthn, dokumentacji FIDO, Apple i Bitwardena oraz ponad 450 komentarzy z dyskusji na Hacker News. Cytaty z dyskusji przytaczam za wątkiem, opinie komentujących są ich własne. Stan na dwunastego października 2026. To nie jest porada bezpieczeństwa dla firm, wdrożenia korporacyjne mają własne reguły i budżety.