Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Passkeys są przedstawiane jako nowoczesna, wygodna i odporna na phishing alternatywa dla tradycyjnych haseł. Ich bezpieczeństwo opiera się na standardzie WebAuthn oraz na lokalnym przechowywaniu i synchronizacji kluczy uwierzytelniających. Najnowsze ustalenia badaczy pokazują jednak, że skuteczność tego modelu zależy nie tylko od samej kryptografii, ale również od jakości implementacji w przeglądarce, systemie operacyjnym i menedżerze poświadczeń.
W centrum zainteresowania znalazł się Google Password Manager działający w przeglądarce Chrome na systemie Windows. Opisane scenariusze wskazują, że lokalne złośliwe oprogramowanie może w określonych warunkach nadużyć mechanizmów związanych z passkeys i doprowadzić do przejęcia dostępu do kont użytkownika.
W skrócie
Badacze opisali trzy techniki ataku określane jako Pass-ta-key, Silver Pass-ta-key oraz Golden Pass-ta-key. Każda z nich koncentruje się na innym etapie obsługi passkeys, ale wspólnym mianownikiem jest wykorzystanie słabości w logice wdrożenia, a nie złamanie standardu WebAuthn.
- Pass-ta-key ma umożliwiać wygenerowanie poprawnej kryptograficznie asercji bez rzeczywistej interakcji użytkownika.
- Silver Pass-ta-key dotyczy przejęcia procesu ponownej rejestracji urządzenia i podstawienia własnego mechanizmu user verification.
- Golden Pass-ta-key koncentruje się na pozyskaniu sekretu używanego do odszyfrowywania zsynchronizowanych kluczy prywatnych passkeys.
Kluczowe zastrzeżenie jest takie, że każdy z tych ataków zakłada wcześniejszą kompromitację endpointu przez malware działające lokalnie z uprawnieniami zwykłego użytkownika.
Kontekst / historia
Opisane techniki zostały ujawnione 3 sierpnia 2026 roku i odnoszą się do architektury Google Password Manager dla Chrome na systemach Windows, zwłaszcza w środowiskach wykorzystujących TPM. To ważne, ponieważ TPM oraz passkeys są powszechnie kojarzone z wysokim poziomem ochrony, a badanie pokazuje, że nawet poprawne fundamenty kryptograficzne nie eliminują ryzyka związanego z warstwą operacyjną.
Badacze podkreślają, że problem nie dotyczy złamania matematycznych podstaw WebAuthn. Zamiast tego chodzi o nadużycie mechanizmów zarządzania kluczami urządzenia, synchronizacji poświadczeń oraz obsługi procesu ponownej rejestracji. To rozróżnienie ma znaczenie praktyczne: passkeys nadal pozostają silniejszym rozwiązaniem niż hasła, ale nie są odporne na ataki post-compromise wykonywane z poziomu już przejętego hosta.
W chwili ujawnienia informacji publicznie dostępne materiały nie wskazywały jednoznacznie pełnego statusu poprawek dla wszystkich ścieżek ataku. Nie pojawiły się też powszechnie przypisane identyfikatory CVE, co utrudnia szybką ocenę skali ekspozycji w środowiskach produkcyjnych.
Analiza techniczna
Pierwsza technika, Pass-ta-key, ma wykorzystywać opakowany klucz tożsamości urządzenia przechowywany przez Chrome oraz ten sam moduł TPM do podpisania żądania kontrolowanego przez atakującego. W rezultacie możliwe jest wygenerowanie prawidłowej kryptograficznie odpowiedzi uwierzytelniającej bez aktywnego udziału użytkownika. Ograniczeniem tego wariantu pozostaje jednak kwestia atrybutu user verification, który może nie zostać ustawiony zgodnie z oczekiwaniami usługi docelowej.
Drugi wariant, Silver Pass-ta-key, dotyczy momentu ponownej rejestracji urządzenia. W tym scenariuszu malware może wykorzystać okno czasowe, w którym następuje re-enrollment, i zarejestrować własny komponent odpowiedzialny za user verification. Jeśli serwis zaakceptuje taki klucz bez odpowiedniej walidacji pochodzenia lub atestacji, napastnik może później tworzyć asercje z wymaganym statusem zweryfikowanego użytkownika już poza urządzeniem ofiary.
Najpoważniejszy scenariusz, Golden Pass-ta-key, opiera się na pozyskaniu 32-bajtowego sekretu domeny bezpieczeństwa, który służy do odszyfrowania zsynchronizowanych prywatnych kluczy passkeys. Zgodnie z opisem badaczy sekret ten może pojawiać się czasowo w pamięci procesu Chrome podczas operacji ponownej rejestracji lub synchronizacji. Jeżeli malware odczyta taki materiał, atakujący może odzyskać prywatne klucze i potencjalnie uzyskać trwały dostęp do kont z własnej infrastruktury.
Analiza sugeruje, że problem leży na styku wielu komponentów: lokalnego magazynu danych przeglądarki, logiki zarządzania kluczami urządzenia, synchronizacji oraz weryfikacji po stronie relying party. Dodatkowo lokalnie przechowywane metadane dotyczące passkeys mogą ułatwiać rekonesans i wskazywać, które konta oraz identyfikatory poświadczeń są najbardziej wartościowe dla napastnika.
Konsekwencje / ryzyko
Najważniejszym skutkiem opisanych technik jest możliwość przejęcia kont uznawanych za lepiej chronione dzięki wdrożeniu passkeys. W praktyce oznacza to, że bezhasłowe uwierzytelnianie nie eliminuje ryzyka, jeżeli stacja robocza została już skompromitowana przez złośliwe oprogramowanie.
Dla użytkowników indywidualnych może to oznaczać utratę dostępu do poczty, usług chmurowych, platform zakupowych czy kont powiązanych z tożsamością federacyjną. W organizacjach ryzyko jest jeszcze większe, ponieważ passkeys mogą chronić dostęp do systemów SSO, paneli administracyjnych, repozytoriów kodu, narzędzi deweloperskich i danych wrażliwych.
Istotnym czynnikiem pozostaje także poprawność implementacji po stronie serwisu. Jeśli aplikacja nie wymusza i nie sprawdza atrybutu user verification lub nie waliduje odpowiednich parametrów WebAuthn po stronie serwera, może zaakceptować asercję poprawną kryptograficznie, ale niespełniającą wymogów silnego potwierdzenia tożsamości użytkownika.
Rekomendacje
Organizacje powinny traktować opisane techniki jako zagrożenie post-compromise i wzmacniać ochronę stacji roboczych. Kluczowe znaczenie mają narzędzia EDR lub XDR, monitorowanie podejrzanych działań w procesach przeglądarki oraz ograniczanie możliwości działania malware w kontekście zwykłego użytkownika.
Z perspektywy zespołów aplikacyjnych i IAM konieczne jest prawidłowe egzekwowanie mechanizmów WebAuthn po stronie serwera. Samo ustawienie preferencji w żądaniu logowania nie wystarcza, jeśli backend nie analizuje wyniku ceremonii uwierzytelnienia.
- wymuszać userVerification jako required tam, gdzie wymaga tego model ryzyka,
- weryfikować atrybuty zwracane przez uwierzytelniacz po stronie serwera,
- stosować silną kontrolę przy ponownej rejestracji urządzeń,
- sprawdzać pochodzenie i atestację nowych kluczy,
- minimalizować ekspozycję sekretów i materiału kluczowego w pamięci procesów klienckich,
- przygotować procedury rotacji i unieważniania sekretów synchronizacji,
- regularnie testować scenariusze obejmujące lokalne malware, a nie tylko ataki zdalne.
Po stronie użytkownika końcowego nadal obowiązują podstawowe zasady higieny bezpieczeństwa: aktualizowanie Chrome i Windows, unikanie uruchamiania niezweryfikowanych plików i skryptów, ograniczanie uprawnień lokalnych oraz szybka reakcja na symptomy kompromitacji urządzenia.
Podsumowanie
Opublikowane badania pokazują, że passkeys pozostają wartościowym mechanizmem uwierzytelniania, ale ich skuteczność zależy od jakości wdrożenia i bezpieczeństwa endpointu. Opisane ataki na Google Password Manager w Chrome na Windows nie podważają fundamentów WebAuthn, lecz pokazują, jak luki w logice obsługi kluczy, rejestracji urządzeń i walidacji user verification mogą osłabić praktyczną ochronę kont.
Dla branży cyberbezpieczeństwa to ważne przypomnienie, że odporność na phishing nie oznacza odporności na lokalne malware. Realna redukcja ryzyka wymaga połączenia silnej walidacji WebAuthn, dojrzałych procesów IAM oraz skutecznej ochrony stacji roboczych.
Źródła
- https://thehackernews.com/2026/08/google-password-manager-attacks-could.html
- https://unit42.paloaltonetworks.com/passwordless-authentication/?_wpnonce=019e1d8dd1&lg=en&pdf=print
- https://www.w3.org/TR/webauthn-3/
- https://chromium.googlesource.com/experimental/chromium/src/%2B/refs/heads/main/chrome/browser/webauthn/enclave_manager.h
- https://support.google.com/accounts/answer/13548313?hl=en