Passkeys czy hasła? Phishing przegrywa, ale 111 witryn działa niespójnie

Klucze dostępu lepiej chronią przed phishingiem niż hasła: poświadczenie jest przypisane do usługi, więc fałszywa witryna nie może użyć go do zalogowania się w prawdziwym serwisie. Analiza NCSC ocenia poświadczenia FIDO2 jako odporne na phishing i co najmniej równie bezpieczne jak tradycyjne uwierzytelnianie wieloskładnikowe w rozpatrywanych atakach na konta prywatne. Dla użytkownika pozostaje jednak kwestia odzyskania dostępu i logowania na innych urządzeniach.

Wygoda nie wynika z samej kryptografii. Opublikowane przez USENIX badanie 111 witryn porównało 28 czynników związanych z odkrywaniem, tworzeniem, używaniem i usuwaniem kluczy. Podstawowe funkcje coraz częściej działają podobnie, ale funkcje pomocnicze pozostają nierówne. To różnice w badanej próbie, a nie twierdzenie, że każda z tych witryn ma tę samą wadę. Wybór między hasłem a kluczem trzeba więc rozpatrywać osobno dla bezpieczeństwa poświadczenia i dla sposobu, w jaki konkretny serwis je obsługuje.

Phishing: dlaczego klucz nie trafia na fałszywą stronę?

Hasło można wpisać w formularzu podstawionym przez oszusta. Kod jednorazowy ogranicza szkody wynikające ze znajomości samego hasła, lecz podczas trwającego logowania napastnik może nakłonić użytkownika do przekazania również kodu. Dlatego hasło z kodem i klucz dostępu nie zapewniają takiej samej ochrony przed stroną podszywającą się pod usługę.

Przy logowaniu kluczem urządzenie podpisuje nowe wyzwanie kryptograficzne, a przeglądarka wiąże operację z domeną właściwej usługi. Wyjaśnienie FIDO Alliance opisuje tę konstrukcję jako odporną zarówno na phishing, jak i na ponowne wykorzystanie przechwyconej odpowiedzi. Odcisk palca, rozpoznanie twarzy albo PIN mogą odblokować klucz lokalnie na urządzeniu; użytkownik nie wpisuje ich w formularzu serwisu.

Przewaga dotyczy ścieżki logowania kluczem. Jeśli to samo konto nadal dopuszcza hasło z kodem, napastnik może skierować atak na tę metodę lub na słabszą procedurę odzyskiwania dostępu. Dla administratora istotny jest zatem cały zestaw dostępnych dróg wejścia na konto, a nie sama obecność przycisku logowania kluczem.

Wyciek bazy: co zostaje po stronie serwisu?

Hasło jest sekretem znanym użytkownikowi, który serwis musi umieć zweryfikować. Powinien przechowywać odpowiednio zabezpieczony skrót hasła, lecz po wycieku bazy słabe hasła nadal mogą zostać odgadnięte. Ponownie użyte hasło może też otworzyć dostęp do innych kont. Siła wybranego hasła, sposób jego przechowywania oraz dodatkowy składnik logowania zmieniają skalę tego ryzyka.

Przy FIDO2 serwis zapisuje klucz publiczny, a odpowiadający mu klucz prywatny pozostaje u uwierzytelniacza. Klucz publiczny ujawniony z bazy nie pozwala podpisać wyzwania logowania. Różnica dotyczy więc tego, co napastnik może zrobić z wykradzionymi danymi uwierzytelniającymi, a nie bezpieczeństwa całej usługi w każdym rodzaju incydentu.

Aktywna sesja przejęta z urządzenia użytkownika jest innym zasobem niż hasło czy klucz prywatny. Tak samo słaba procedura odzyskania konta może dać dostęp bez złamania kryptografii FIDO2. Przy ocenie skutków wycieku warto oddzielić bazę poświadczeń od sesji, urządzeń i zasad obsługi konta.

Utrata urządzenia: od czego zależy powrót do konta?

Klucz dostępu synchronizowany przez menedżera poświadczeń może być dostępny na innym autoryzowanym urządzeniu lub po odzyskaniu konta u dostawcy synchronizacji. Inaczej działa poświadczenie FIDO2 związane z jednym urządzeniem albo zapisane na fizycznym kluczu bezpieczeństwa: jego jedyna kopia może zniknąć razem z urządzeniem. Wtedy znaczenie ma wcześniej dodany drugi uwierzytelniacz lub procedura odzyskiwania konta w serwisie.

Hasło zapamiętane przez użytkownika nie znika wraz z telefonem, choć utrata telefonu może odciąć dostęp do kodów drugiego składnika. Hasło zapisane w menedżerze zależy z kolei od możliwości odzyskania tego menedżera. Porównanie „hasło kontra klucz” daje więc niepełną odpowiedź, dopóki nie wiadomo, gdzie poświadczenie jest przechowywane i jakie kopie są dostępne.

Synchronizacja ułatwia powrót po awarii, ale przenosi część odpowiedzialności na konto dostawcy poświadczeń i jego procedurę odzyskiwania. Klucz związany z pojedynczym urządzeniem wymaga zaplanowania zapasowej metody wcześniej. W obu wariantach słaby PIN urządzenia lub dostęp osoby niepowołanej do odblokowanego sprzętu pozostają realnymi zagrożeniami.

Różne ekosystemy: synchronizacja czy telefon pod ręką?

Klucz zapisany u jednego dostawcy nie musi automatycznie pojawić się w każdym systemie i przeglądarce. Opis Google dla Androida i Chrome przedstawia synchronizację przez Menedżera haseł Google w obsługiwanych środowiskach oraz logowanie kluczem z innego telefonu po zeskanowaniu kodu QR. W drugim wariancie telefon zatwierdza logowanie, ale klucz nie musi być przenoszony na urządzenie, na którym otwarto serwis.

To odczuwalna różnica dla osoby używającej na co dzień telefonu i komputera z różnych ekosystemów. Na jednym urządzeniu wybór zapisanego klucza może być krótki, podczas gdy na drugim trzeba sięgnąć po telefon i potwierdzić operację. Zanim uzna się klucz za wygodniejszy od hasła, trzeba wiedzieć, czy używany menedżer udostępnia go na potrzebnych urządzeniach oraz czy serwis pozwala dodać więcej niż jedno poświadczenie do konta.

Dlaczego obsługa witryn pozostaje nierówna?

W pełnej analizie wdrożeń, prowadzonych od lutego 2025 do lutego 2026 roku, na 21% badanych witryn klucza utworzonego w serwisie nie dało się użyć w odpowiadającej mu aplikacji mobilnej, a autouzupełnianie kluczy oferowało 42% próby. Badacze oceniali dostępne ścieżki i funkcje, a nie czas logowania czy satysfakcję użytkowników. Witryny wybrano z katalogu usług obsługujących klucze, więc wynik nie opisuje wszystkich serwisów dostępnych w Polsce.

Rozbieżność pojawia się także między rejestracją a użyciem klucza. Część witryn pokazywała przy logowaniu możliwość skorzystania z telefonu lub fizycznego uwierzytelniacza, lecz nie dawała równie dostępnej drogi dodania takiego urządzenia do konta. Dla użytkownika wygląda to jak obsługiwana metoda, której nie może przygotować do własnego logowania.

Lista zarejestrowanych kluczy, ich usuwanie i spójność między witryną a aplikacją decydują o tym, czy użytkownik rozumie, które urządzenie zapewni mu dostęp. Te elementy nie zmieniają sposobu podpisywania wyzwania kryptograficznego. Zmieniają za to codzienne doświadczenie korzystania z metody, której podstawowy mechanizm jest taki sam w różnych usługach.

Co rozstrzyga wybór?

Jeżeli serwis poprawnie obsługuje klucz dostępu, jego użycie do codziennego logowania ma mocne uzasadnienie: ogranicza phishing i nie pozostawia w bazie serwisu hasła, które można odgadnąć lub wykorzystać ponownie. Wygoda zależy od tego, czy klucz jest dostępny na używanych urządzeniach oraz jak działa powrót do konta po utracie jednego z nich.

Przy wdrożeniu administrator powinien ocenić rejestrację, logowanie, zarządzanie kluczami i odzyskiwanie dostępu jako jedną drogę użytkownika. Szczególnej uwagi wymaga sytuacja, w której interfejs obiecuje logowanie z urządzenia, którego nie pozwala wcześniej dodać, oraz konto zachowujące słabszą metodę wejścia mimo uruchomienia FIDO2.

Przeczytaj także:

• Patent czy tajemnica? Ochrona bez rejestracji nie daje monopolu
• CapCut czy DaVinci Resolve? Szybki eksport nie rozstrzyga wyboru
• Karta czy BLIK w e-sklepie? Chargeback działa tylko po jednej stronie