Sierpniowa dyskusja o Pass-ta-key nie jest powodem, by porzucać passkeys. Jest powodem, by przestać traktować je jak magię. Unit 42 opisała ataki na synchronizowane passkeys Google Password Manager w Chrome na Windows. Ars Technica dodała ważne uspokojenie: to nie znaczy, że passkeys są złamane. To znaczy, że „odporne na phishing” nie oznacza „odporne na komputer, na którym już działa malware”.

Schemat: passkeys blokują phishing, przejęty endpoint pozostaje ryzykiem, klucze sprzętowe chronią konta krytyczne

Co się stało i czego nie wolno wnioskować

Badanie Unit 42 dotyczy konkretnego środowiska: Google Password Manager, Chrome na Windows, cloud authenticator i zaufanie do urządzenia oparte częściowo na TPM. Warianty nazwano Pass-ta-key, Silver Pass-ta-key i Golden Pass-ta-key. Najważniejszy warunek jest mniej efektowny: na urządzeniu ofiary musi już działać złośliwy kod. To nie jest zdalne złamanie WebAuthn ani fałszywa strona, która kradnie passkey jak hasło.

Dokładniejszy wniosek brzmi: lokalny malware może nadużywać stanu przeglądarki, onboarding urządzeń, recovery i ustawienia user verification wokół synchronizowanych passkeys. W zależności od konfiguracji usługi może to dać dostęp bez nowej widocznej akcji użytkownika, ominąć oczekiwaną weryfikację albo wydobyć zsynchronizowany materiał przydatny atakującemu. To poważne dla zespołów bezpieczeństwa, ale nie unieważnia ochrony przed typowym phishingiem.

Ars słusznie studzi emocje. Gdy endpoint jest już przejęty, zagrożone są cookies, tokeny OAuth, profile przeglądarki, sejfy haseł, pliki, powiadomienia i procesy odzyskiwania konta. Passkeys zastępują współdzielony sekret i ograniczają skuteczność fałszywych formularzy logowania. Nie zastępują ochrony endpointu, izolacji systemu i reakcji na incydenty.

Jak działa ochrona passkey

Passkey to poświadczenie FIDO/WebAuthn oparte na kryptografii klucza publicznego. Authenticator tworzy parę kluczy dla konkretnego relying party. Serwis przechowuje klucz publiczny, a prywatny pozostaje pod kontrolą authenticatora lub dostawcy passkeys. Przy logowaniu serwis wysyła challenge, authenticator podpisuje dane związane z właściwym origin, a przeglądarka zwraca assertion. Zależnie od polityki użytkownik odblokowuje urządzenie, używa PIN, biometrii albo dotyka klucza.

To zmienia ekonomię ataku. Fałszywa strona nie dostaje hasła do ponownego użycia. Wyciek bazy serwera nie daje hashy, które można testować gdzie indziej. Credential stuffing traci paliwo. FIDO i W3C mówią o odporności na phishing, bo odpowiedź kryptograficzna jest związana z prawdziwym origin, a nie wyglądem strony.

Odporność na phishing nie jest odpornością na malware. Oznacza, że zdalna strona-pułapka nie powinna zdobyć wielorazowego sekretu. Nie oznacza, że zainfekowany laptop nie może działać w zaufanym profilu, uruchamiać dozwolonych flow, czekać na odblokowanie, czytać lokalnego stanu lub używać aktywnych sesji. Granice ochrony są szerokie, ale istnieją.

Co pokazała Unit 42

Marcowy tekst Unit 42 tłumaczył mechanizmy Google Cloud Authenticator dla synchronizowanych passkeys. Sierpniowy pokazał, jak Chrome na Windows, lokalne dane synchronizacji, TPM i zaufanie do urządzenia mogą utworzyć trudne założenia bezpieczeństwa. Zakres trzeba powtarzać: Google Password Manager w Chrome na Windows z TPM, odpowiedzialne ujawnienie i malware obecny na urządzeniu.

Pierwsza lekcja dotyczy zaufania do urządzenia. Jeśli kod atakującego działa tam, gdzie działa przeglądarka i konto Google, może próbować wyglądać jak legalny kontekst. Druga dotyczy user verification: dla kont i operacji wrażliwych “preferred” może być za słabe, a “required” powinno być świadomą decyzją. Trzecia dotyczy synchronizacji. Jest wygodna i często bezpieczniejsza od powrotu do haseł, ale recovery, backup i onboarding stają się częścią powierzchni ataku.

Nie wynika z tego zakaz synchronizowanych passkeys dla wszystkich. Dla zwykłego użytkownika są często lepsze niż hasło plus SMS. Dla administratorów, finansów, maintainerów kodu i zarządu potrzebne mogą być hardware security keys, urządzenia zarządzane, conditional access i surowsze enrollment.

Dlaczego nadal są ważne

Phishing haseł pozostaje masowy. Ponowne używanie haseł zamienia jeden wyciek w wiele przejęć. Kody SMS i OTP można przechwytywać przez zestawy adversary-in-the-middle. Passkeys bezpośrednio zmniejszają te ryzyka. Rozsądna reakcja na sierpniowe nagłówki to zostawić passkeys włączone i poprawić higienę urządzeń, nie wracać do słabych haseł.

Usługi muszą implementować WebAuthn dokładnie. Challenge ma być unikalny, losowy, krótko ważny i powiązany z sesją oraz operacją. Serwer musi sprawdzać origin, relying party ID, podpis i replay. User verification dla ważnych kont nie powinien być przypadkowo opcjonalny. Dodanie nowej passkey wymaga świeżo potwierdzonej sesji, powiadomienia i mocnej ochrony recovery.

Google opisuje passkeys jako prostszą i bezpieczniejszą alternatywę dla haseł. To dobre dla użytkownika, ale technicznie synchronizowane passkeys obejmują chmurę, onboarding, recovery i lokalny stan przeglądarki. Użytkownik nie wpisuje klucza prywatnego na fałszywej stronie; malware może jednak atakować system wokół niego.

Wskazówki dla użytkowników

Zostaw passkeys na ważnych kontach. Używaj mocnej blokady ekranu na każdym urządzeniu, które potwierdza logowanie. Usuń stare telefony, laptopy i przeglądarki z paneli bezpieczeństwa. Sprawdź e-mail i telefon odzyskiwania, bo recovery często jest najsłabszą drogą. Nie loguj się do poczty głównej, banku, konta deweloperskiego lub konsoli chmurowej na cudzym komputerze.

Ogranicz rozszerzenia przeglądarki. Rozszerzenie z szerokimi uprawnieniami jest blisko stron, promptów i sesji. Aktualizuj system i przeglądarkę. Po infekcji traktuj sprzątanie jak incydent tożsamości: odwołaj sesje, sprawdź dodane passkeys, usuń nieznane urządzenia, przejrzyj reguły poczty i zgody OAuth. Samo usunięcie malware nie zamyka sprawy.

Dla kont najważniejszych użyj fizycznego klucza bezpieczeństwa i zapasowego drugiego klucza. To mniej wygodne niż synchronizacja, ale ogranicza zależność od typowego stanu komputera. Nie jest to magia: recovery i bezpieczeństwo po zalogowaniu nadal mają znaczenie.

Wskazówki dla organizacji

Firma powinna najpierw sklasyfikować role. Kto potrzebuje ochrony przed masowym phishingiem? Kto może zmieniać politykę tożsamości, płatności, produkcję lub dane regulowane? Które urządzenia są zarządzane, szyfrowane, łatane i monitorowane? Którzy dostawcy passkeys są dozwoleni? Gdzie synchronizacja jest akceptowalna, a gdzie wymagane są klucze sprzętowe albo urządzenia zarządzane?

Dla zwykłych kont synchronizowane passkeys mogą być wielkim krokiem naprzód wobec haseł i SMS. Dla ról uprzywilejowanych polityka może wymagać hardware keys, zgodności urządzeń, stacji administracyjnych i czasowego podnoszenia uprawnień. Trzeba też oddzielać linię Unit 42 o Google/Chrome/Windows od linii SpecterOps/Microsoft Entra o WebAuthn, Windows 11, logging assertion i replay validation. To nie jeden błąd, lecz wspólna lekcja o szczegółach implementacji.

Reakcja na incydent również musi być inna. Przy przejętym endpointcie reset hasła nie wystarcza. Należy odwołać sesje, usunąć urządzenia, przejrzeć nowe passkeys, zmienić recovery factors, sprawdzić OAuth grants, ponownie zarejestrować zaufanie i czytać logi logowania. Passwordless wymaga passwordless playbooków.

Spokojny wniosek

Passkeys nie są martwe i nie są magiczne. Mocno poprawiają logowanie, bo usuwają wielorazowy sekret. Ograniczają phishing, credential stuffing i szkody z ponownego użycia haseł. Nie usuwają malware, słabego recovery ani złej implementacji WebAuthn. Praktyczna zasada: używaj passkeys, chroń urządzenia, stosuj klucze sprzętowe dla kont krytycznych i traktuj WebAuthn jak protokół, nie slogan.