Passkeys miały ograniczyć zależność od haseł, ale obsługuje je tylko 11,3% przebadanych popularnych stron — pierwszy spis 100 tysięcy witryn pokazuje skalę fragmentacji

Passkeys miały sprawić, że hasło przestanie być centralnym punktem logowania. Zamiast wpisywania sekretu, który można wyłudzić, przechwycić albo wykorzystać po wycieku bazy danych, użytkownik potwierdza dostęp odciskiem palca, skanem twarzy lub kodem PIN urządzenia. Technicznie mechanizm jest dojrzały. Problem zaczyna się kilka centymetrów dalej — na stronie internetowej, która musi go jeszcze wdrożyć.

Pierwszy szeroki spis wykorzystania passkeys na 100 tys. popularnych domen z rankingu Tranco pokazuje, jak duża pozostaje ta luka. Autorzy badania określają skalę obsługi passkeys na 11,3% przeskanowanych witryn. W samym zbiorze wykryli 9397 serwisów z sygnałami obsługi passkeys. To znacznie więcej niż sugerowały wcześniej ręcznie prowadzone katalogi, ale zdecydowanie za mało, by użytkownik mógł faktycznie przestać myśleć o hasłach.

Co ważniejsze, samo słowo „obsługuje” okazuje się pojemne. Część stron korzysta z WebAuthn bezpośrednio, część tylko pośrednio przez logowanie kontem Google, Microsoftu czy Apple, a w innych opcja pojawia się dopiero po wpisaniu adresu e-mail albo po interakcji z formularzem. Passkeys nie tworzą dziś jednolitego środowiska logowania. To raczej kilka nakładających się ekosystemów wykorzystujących ten sam standard kryptograficzny.

11,3% brzmi słabo. Szczegóły badania są jeszcze ciekawsze

Badanie przeprowadzono za pomocą narzędzia Fidentikit, które analizowało 100 tys. domen z listy Tranco. To ważne, bo zwykłe sprawdzenie kodu HTML strony nie wystarcza do znalezienia passkeys.

Badacze wykorzystali 43 heurystyki podzielone na pięć grup. Narzędzie szukało między innymi:

• napisów i elementów interfejsu sugerujących logowanie kluczem dostępu,

• charakterystycznych struktur DOM,

• wywołań API WebAuthn, w tym navigator.credentials,

• zapytań sieciowych związanych z uwierzytelnianiem,

• bibliotek JavaScript obsługujących WebAuthn,

• zewnętrznych dostawców tożsamości, takich jak Google, Microsoft, Apple i GitHub.

Reguły opracowano po ręcznym przeanalizowaniu ponad 1500 witryn. To istotny szczegół, bo passkey może istnieć na stronie, mimo że użytkownik nie zobaczy przycisku „Zaloguj się kluczem dostępu”.

Aż 82,3% wykrytych wdrożeń zostało zauważonych dzięki obserwowaniu działania API w JavaScripcie. Analiza tekstów i przycisków na stronie wykrywała jedynie 4,5% przypadków. Biblioteki JavaScript dawały sygnał w 18,6%, integracje OAuth klasy enterprise w 11,4%, a zewnętrzni dostawcy tożsamości pojawiali się w 75,2% wdrożeń. Kategorie nakładają się na siebie, więc procentów nie należy sumować.

To tłumaczy, dlaczego wcześniejsze katalogi wyglądały tak skromnie. Fidentikit znalazł 9397 witryn, podczas gdy ręczne zestawienia obejmowały setki, nie tysiące serwisów. 96,2% stron wykrytych przez crawler nie znajdowało się w żadnym z dwóch porównywanych katalogów.

Jest jednak metodologiczny haczyk, którego nie powinno się pomijać. Nie wszystkie 100 tys. domen udało się faktycznie przeanalizować.

Badacze podają łącznie:

• 20 706 niedostępnych domen — np. problem z DNS albo odpowiedź 404,

• 921 przypadków, w których crawler nie znalazł odpowiedniej strony logowania,

• 175 timeoutów podczas automatyzacji.

Łącznie daje to 21 802 problematyczne witryny.

W publikacji jako główny wynik widnieje 11,3% przeskanowanych stron, ale jednocześnie podane liczby 9397 wykrytych witryn oraz zestawienie problemów z dostępnością nie pozwalają odtworzyć tej wartości prostym dzieleniem. To ważne ograniczenie przy cytowaniu badania: 11,3% należy traktować jako wskaźnik raportowany przez autorów, a nie jako 9397 podzielone przez pełne 100 tys. domen.

Jeszcze ciekawsza jest zależność od popularności strony. Wśród 100 najpopularniejszych witryn około 20% obsługiwało passkeys. W grupie domen zajmujących miejsca 50 000–100 000 było to już tylko 6,9%.

To praktycznie oznacza, że passkeys najłatwiej spotkać tam, gdzie firmy mają duże zespoły bezpieczeństwa, wysokie koszty przejęć kont i miliony logowań miesięcznie. Im dalej schodzimy w stronę regionalnych sklepów, mniejszych platform SaaS czy wyspecjalizowanych serwisów, tym szybciej użytkownik wraca do starego zestawu: adres e-mail, hasło, kod jednorazowy.

Największa fragmentacja nie leży w kryptografii, tylko w sposobie logowania

Sam mechanizm WebAuthn jest stosunkowo spójny. Serwis przechowuje klucz publiczny, a odpowiadający mu klucz prywatny pozostaje po stronie użytkownika — w urządzeniu, kluczu sprzętowym albo menedżerze poświadczeń.

To fundamentalnie zmienia model bezpieczeństwa. Klasyczne hasło jest sekretem znanym obu stronom. Jeżeli baza danych zostanie źle zabezpieczona albo użytkownik poda hasło na stronie phishingowej, atakujący może zdobyć materiał umożliwiający logowanie.

Passkey działa inaczej. Uwierzytelnienie jest powiązane kryptograficznie z właściwą domeną. Fałszywa strona podszywająca się pod bank czy Google nie może po prostu poprosić użytkownika o wpisanie klucza prywatnego, bo użytkownik nigdy go nie wpisuje.

Mocny fundament techniczny nie oznacza jednak jednolitego doświadczenia.

Na jednej stronie zobaczymy:

Zaloguj się kluczem dostępu.

Na drugiej:

Więcej sposobów logowania → Passkey.

Na trzeciej nic. Dopiero po wpisaniu adresu e-mail pojawia się odpowiednia opcja.

Czwarta strona wykorzystuje tzw. conditional mediation. Passkey pojawi się dopiero w systemowym menu autouzupełniania formularza.

Piąta nie wdraża WebAuthn we własnym systemie w ogóle, ale oferuje „Kontynuuj z Google”. Jeżeli użytkownik zabezpieczył konto Google za pomocą passkey, logowanie do docelowego serwisu faktycznie może odbyć się bez podawania hasła.

I właśnie ta ostatnia metoda odpowiada za ogromną część wykrytej adopcji.

75,2% witryn uznanych za obsługujące passkeys integrowało Google SSO. Wśród serwisów korzystających z zewnętrznych dostawców Google pojawiało się zdecydowanie najczęściej. Microsoft odpowiadał mniej więcej za 15–18%, Apple za 8–12%, a GitHub za 5–8% przypadków w poszczególnych grupach rankingu.

To wygodna droga dla właściciela strony. Nie musi od razu projektować całego procesu rejestracji, przechowywania publicznych poświadczeń, dodawania kolejnych passkeys, odzyskiwania konta i obsługi sytuacji awaryjnych.

Ale jest cena. Serwis przenosi część kontroli nad uwierzytelnianiem do zewnętrznego dostawcy tożsamości.

Gdy użytkownik loguje się przez Google, właściciel docelowej witryny dostaje wynik procesu OAuth. Nie musi wiedzieć, czy użytkownik po stronie Google użył passkey, hasła, aplikacji uwierzytelniającej czy innej metody.

Dlatego stwierdzenie „strona obsługuje passkeys” nie zawsze oznacza: „na tej stronie mogę utworzyć własny passkey przypisany bezpośrednio do konta”.

To jedna z najważniejszych rzeczy do sprawdzenia w praktyce.

Passkey warto włączać już teraz, ale hasła jeszcze nie można wyrzucić

Dla użytkownika w Polsce najrozsądniejsza strategia jest dziś prosta: włączać passkeys tam, gdzie są dostępne, ale nie projektować swojego bezpieczeństwa tak, jakby hasła już przestały istnieć.

Google Password Manager synchronizuje passkeys pomiędzy obsługiwanymi urządzeniami powiązanymi z kontem Google. Apple robi podobnie przez iCloud Keychain na urządzeniach należących do ekosystemu Apple. Windows 11 obsługuje passkeys przez Windows Hello, a Microsoft rozwija również obsługę poświadczeń synchronizowanych. Menedżery firm trzecich, takie jak 1Password, również mogą przechowywać i synchronizować passkeys.

Najmniej problemów ma użytkownik, który korzysta głównie z jednego ekosystemu. iPhone + Mac albo Android + Chrome jest zwykle łatwiejszy w obsłudze niż ciągłe przechodzenie pomiędzy kilkoma dostawcami poświadczeń.

Fragmentację najlepiej widać podczas korzystania z cudzych lub nowych urządzeń. Czasami system pozwoli użyć telefonu i zeskanować kod QR, po czym komunikacja między urządzeniami umożliwi potwierdzenie logowania. Innym razem pojawi się kilka podobnych komunikatów: passkey z telefonu, Windows Hello, menedżer haseł, klucz sprzętowy. Dla osoby technicznej różnica jest jasna. Dla przeciętnego użytkownika — często nie.

Najbardziej irytujący etap zaczyna się po zmianie urządzenia albo ekosystemu. Sam standard passkeys jest międzyplatformowy, ale miejsce przechowywania poświadczenia nadal ma znaczenie. FIDO rozwija standardy bezpiecznej wymiany poświadczeń między dostawcami, a producenci systemów rozszerzają import i eksport, lecz nie warto jeszcze zakładać, że każde poświadczenie zapisane w jednym menedżerze da się bezproblemowo przenieść do dowolnego innego.

Dlatego przy ważnych kontach warto stosować konkretną kolejność.

Priorytet 1: zabezpieczyć konta będące „kluczem do innych kont”.
Najpierw poczta elektroniczna, konto Google, Apple lub Microsoft oraz główny menedżer haseł. Przejęcie skrzynki pocztowej nadal często pozwala resetować dostęp do kolejnych usług.

Priorytet 2: dodać więcej niż jeden sposób odzyskania dostępu.
Jeżeli serwis pozwala utworzyć kilka passkeys, dobrze mieć poświadczenie na więcej niż jednym zaufanym urządzeniu albo dodatkowy klucz sprzętowy. Nie należy natomiast tworzyć passkey na współdzielonym komputerze tylko dlatego, że przeglądarka go proponuje.

Priorytet 3: nie usuwać metody awaryjnej bez sprawdzenia procedury odzyskiwania konta.
Najpierw trzeba ustalić, co wydarzy się po zgubieniu telefonu, awarii laptopa i utracie dostępu do menedżera poświadczeń. Dopiero potem można rozważać całkowite wyłączenie hasła, jeśli dany serwis faktycznie na to pozwala.

W firmach problem jest trudniejszy. Samo dodanie WebAuthn do formularza logowania nie kończy projektu. Trzeba zaprojektować:

• rejestrację pierwszego passkey,

• dodawanie kolejnych urządzeń,

• usuwanie zgubionych poświadczeń,

• odzyskiwanie konta,

• obsługę pracownika tracącego telefon,

• politykę dla administratorów i kont uprzywilejowanych,

• fallback dla urządzeń nieobsługujących wybranego rozwiązania,

• zabezpieczenie przed tym, by słaby proces recovery nie omijał mocnego logowania.

Ten ostatni punkt jest szczególnie ważny. Passkey odporny na phishing niewiele daje, jeżeli napastnik może ominąć go przez banalny reset konta oparty na słabym kanale odzyskiwania.

W przypadku administratorów, osób mających dostęp do finansów albo infrastruktury produkcyjnej sens ma dodatkowo rozważenie sprzętowych, powiązanych z urządzeniem kluczy FIDO2, zamiast polegania wyłącznie na synchronizowanych passkeys. Wygoda jest wtedy mniejsza, ale ogranicza się powierzchnię ataku związaną z synchronizacją.

Badanie dobrze pokazuje też, gdzie rynek przyspiesza. Wśród sklasyfikowanych stron z passkeys 26,5% należało do kategorii biznes i finanse, 22% do handlu, a 9,4% do technologii i komputerów. W grupie 847 przeanalizowanych serwisów bankowych i finansowych autorzy wykryli obsługę passkeys w 312 przypadkach, czyli 36,8%.

To nie przypadek. Bank, sklep internetowy czy platforma płatnicza potrafią policzyć koszt przejęcia konta, phishingu i fraudu. Passkeys rozwiązują tam konkretny problem finansowy. Sektory, które nie widzą równie bezpośredniego zwrotu z inwestycji, wdrażają je wolniej.

Dla właściciela polskiego serwisu decyzja powinna więc wyglądać następująco: jeżeli użytkownicy posiadają konta, przechowują dane osobowe, płacą albo wykonują operacje mające wartość finansową, WebAuthn powinien już znaleźć się na roadmapie uwierzytelniania. Najszybszym rozwiązaniem może być zewnętrzny dostawca tożsamości, lecz serwis wymagający większej kontroli powinien rozważyć natywne passkeys i przede wszystkim dobrze zaprojektowane odzyskiwanie kont.

Dla użytkownika decyzja jest jeszcze łatwiejsza. Jeżeli zaufany serwis pozwala utworzyć passkey, zwykle warto to zrobić. Nie trzeba jednak kasować menedżera haseł. Przy adopcji rzędu kilkunastu procent to właśnie on nadal pozostaje narzędziem spinającym starą i nową rzeczywistość logowania.

FAQ: passkeys w praktyce

Czy passkey jest tym samym co hasło zapisane w telefonie?
Nie. Passkey wykorzystuje parę kluczy kryptograficznych. Serwis otrzymuje klucz publiczny, natomiast klucz prywatny pozostaje w urządzeniu lub menedżerze poświadczeń i nie jest wpisywany na stronie.

Czy passkeys są odporne na phishing?
Na klasyczny phishing polegający na wyłudzeniu danych logowania — tak. Poświadczenie WebAuthn jest związane z właściwą domeną, więc fałszywa strona nie może po prostu przejąć go tak jak wpisanego hasła. Nie oznacza to odporności na każdy rodzaj ataku, np. kradzież aktywnej sesji po poprawnym zalogowaniu.

Czy można całkowicie zrezygnować z haseł?
Tylko w części usług. Wiele stron oferuje passkey jako dodatkową metodę logowania, ale nadal utrzymuje hasło albo inną procedurę odzyskiwania. Przy obecnej fragmentacji internetu całkowite porzucenie menedżera haseł jest przedwczesne.

Co się stanie po zgubieniu telefonu z passkey?
To zależy od sposobu przechowywania. Passkey synchronizowany przez iCloud Keychain, Google Password Manager albo kompatybilny menedżer może być dostępny na innych autoryzowanych urządzeniach. Poświadczenie związane wyłącznie z jednym urządzeniem trzeba natomiast wcześniej zabezpieczyć alternatywną metodą dostępu.

Czy odcisk palca albo Face ID trafia do strony internetowej?
Nie. Biometria służy lokalnie do odblokowania poświadczenia. Witryna otrzymuje kryptograficzne potwierdzenie uwierzytelnienia, a nie obraz twarzy czy dane odcisku palca.

Co sprawdzić jako pierwsze?
Otwórz ustawienia bezpieczeństwa najważniejszych kont: poczty, Google, Apple, Microsoft, banku i menedżera haseł. Jeśli jest opcja passkey / klucz dostępu, dodaj ją na własnym, zabezpieczonym urządzeniu. Następnie sprawdź procedurę odzyskiwania konta i dopiero później ograniczaj starsze metody logowania. Największym błędem nie jest dziś pozostawienie hasła. Jest nim używanie passkey bez planu na utratę urządzenia.