Wprowadzenie do problemu / definicja
Passkeys są przedstawiane jako nowoczesna alternatywa dla haseł i jeden z najważniejszych elementów uwierzytelniania odpornego na phishing. Ich przewaga wynika z wykorzystania kryptografii asymetrycznej, lokalnej ochrony klucza prywatnego oraz ograniczenia ryzyka ponownego użycia poświadczeń przez atakujących.
Najnowsze badania pokazują jednak, że bezpieczeństwo passkeys nie zależy wyłącznie od samego standardu FIDO2 i WebAuthn. Równie istotne są implementacje w systemie operacyjnym, przeglądarce, usługach tożsamości oraz mechanizmach synchronizacji kluczy między urządzeniami.
W skrócie
- Badacze opisali kilka scenariuszy, w których możliwe było obejście części gwarancji bezpieczeństwa passkeys bez łamania kryptografii.
- Jeden z ataków dotyczył ponownego użycia podpisanych danych uwierzytelniających w środowisku Windows i Microsoft Entra ID.
- Drugi scenariusz pokazał ryzyko związane z synchronizowanymi passkeys w Chrome i możliwością odzyskania kluczy prywatnych po kompromitacji sekretu ochronnego.
- Trzeci przypadek objął Windows Hello for Business, gdzie złośliwy kod w przejętej sesji użytkownika mógł użyć klucza bez ponownego żądania PIN-u lub biometrii.
Kontekst / historia
W ostatnich latach organizacje szeroko wdrażały passkeys jako odpowiedź na phishing, credential stuffing oraz przejmowanie kont za pomocą wykradzionych haseł i kodów jednorazowych. Model ten miał ograniczyć skuteczność klasycznych kampanii wyłudzających dostęp, ponieważ poświadczenie jest powiązane z konkretną usługą i urządzeniem lub kontem użytkownika.
Nowe analizy nie wskazują na złamanie matematycznych podstaw FIDO2. Problemem okazuje się raczej otoczenie implementacyjne, które może dopuścić do nadużycia wcześniej wygenerowanych podpisów, odzyskania materiału kluczowego z pamięci procesu albo użycia legalnego klucza w już skompromitowanej sesji.
Analiza techniczna
Pierwszy łańcuch ataku dotyczy środowiska Windows oraz integracji z Microsoft Entra ID. Badacze wykazali, że wcześniejsze podpisy generowane z użyciem kluczy sprzętowych mogły pozostać w systemie w formie dostępnej dla uwierzytelnionego użytkownika o niskich uprawnieniach. W połączeniu z walidacją po stronie dostawcy tożsamości dawało to możliwość ponownego użycia materiału uwierzytelniającego i osiągnięcia efektu zbliżonego do poprawnego logowania z phishing-resistant MFA.
Drugi obszar badań skupił się na synchronizowanych passkeys przechowywanych w Google Password Manager w przeglądarce Chrome na Windows. W tym scenariuszu zakładano wcześniejsze uruchomienie malware na urządzeniu ofiary, ale bez konieczności uzyskiwania uprawnień administratora. Najpoważniejszy wariant obejmował przejęcie tzw. Security Domain Secret, czyli głównego sekretu używanego do ochrony zsynchronizowanych passkeys. Po jego pozyskaniu możliwe stawało się odzyskanie kluczy prywatnych dla wybranych poświadczeń.
Badacze zwrócili także uwagę, że taki sekret mógł wcześniej pojawiać się w logach urządzenia, a po zmianach nadal może czasowo występować w pamięci procesu podczas ponownej rejestracji. Z punktu widzenia obrony oznacza to, że kompromitacja endpointu może przełożyć się na długofalowe ryzyko dla wielu kont zabezpieczonych passkeys.
Trzeci scenariusz dotyczył Windows Hello for Business. Choć klucz uwierzytelniający pozostaje zwykle chroniony przez TPM i nie powinien być eksportowalny, złośliwe oprogramowanie działające w aktywnej sesji użytkownika mogło wywołać systemowe interfejsy kryptograficzne i użyć tego klucza bez ponownego wymuszenia PIN-u lub biometrii. To podważa praktyczne założenie, że każda operacja użycia klucza wymaga bezpośredniej interakcji użytkownika.
Wspólnym mianownikiem wszystkich opisanych badań nie jest słabość samej kryptografii, ale błędy w warstwach towarzyszących. Ostateczne bezpieczeństwo passkeys zależy od ochrony pamięci procesów, poprawnego logowania zdarzeń, walidacji asercji oraz ścisłego powiązania odpowiedzi kryptograficznych z właściwym kontekstem użytkownika, urządzenia i sesji.
Konsekwencje / ryzyko
Dla organizacji największym zagrożeniem jest fałszywe poczucie pełnej odporności na przejęcie kont po wdrożeniu passkeys. Opisane przypadki pokazują, że po kompromitacji stacji roboczej lub sesji użytkownika atakujący może nadal uzyskać dostęp do kont, nawet jeśli polityki bezpieczeństwa wymagają MFA odpornego na phishing.
Nie są to ataki zdalne wykonywane przez anonimowego napastnika bez wcześniejszego dostępu do urządzenia. Ich znaczenie polega jednak na tym, że znacznie zwiększają skutki skutecznej infekcji endpointu. W praktyce passkeys ograniczają phishing, ale nie eliminują ryzyka wynikającego z malware, wycieków z pamięci, lokalnych logów czy błędów sesyjnych.
Szczególnie istotny jest scenariusz odzyskania kluczy prywatnych dla synchronizowanych passkeys, ponieważ może prowadzić do bardziej trwałej kompromitacji niż jednorazowe przejęcie sesji. Z kolei możliwość użycia Windows Hello for Business bez ponownego potwierdzenia obecności użytkownika osłabia zaufanie do lokalnych mechanizmów user verification.
Rekomendacje
Organizacje powinny traktować passkeys jako silny element architektury IAM, ale nie jako samodzielne rozwiązanie problemu przejęć kont. Kluczowe pozostaje bezpieczeństwo stacji roboczych, szybkie wdrażanie poprawek oraz monitoring anomalii w warstwie tożsamości.
- Priorytetowo wdrażać aktualizacje bezpieczeństwa systemu Windows i komponentów związanych z logowaniem oraz obsługą poświadczeń.
- Monitorować nietypowe użycie Windows Hello for Business, w tym logowania odbiegające od oczekiwanego kontekstu urządzenia i sesji.
- Analizować nowe lub nieoczekiwane rejestracje urządzeń powiązane z kontami uprzywilejowanymi.
- Traktować pamięć przeglądarek, magazyny passkeys i procesy odzyskiwania poświadczeń jako obszary o wysokiej wrażliwości.
- Wzmacniać EDR i XDR na stacjach roboczych, ponieważ część scenariuszy wymaga już działającego malware.
- Weryfikować implementację WebAuthn po stronie aplikacji, w tym poprawne egzekwowanie mechanizmów user verification.
- Ograniczać uprawnienia lokalne oraz stosować segmentację administracyjną dla kont o wysokim poziomie dostępu.
Zespoły bezpieczeństwa powinny również zrewidować modele zagrożeń dla passkeys. Ochrona przed phishingiem nie jest równoznaczna z ochroną przed nadużyciem klucza w skompromitowanej sesji. Dlatego passkeys warto łączyć z kontrolami kontekstowymi, oceną stanu urządzenia, detekcją anomalii sesyjnych oraz zasadą najmniejszych uprawnień.
Podsumowanie
Nowe badania nad atakami na passkeys nie obalają fundamentów kryptograficznych FIDO2, ale wyraźnie pokazują, że rzeczywista odporność uwierzytelniania zależy od całego łańcucha implementacyjnego. System operacyjny, przeglądarka, dostawca tożsamości i mechanizmy synchronizacji wspólnie tworzą powierzchnię ataku, która może osłabić praktyczne korzyści z wdrożenia tego modelu.
Dla organizacji najważniejszy wniosek jest prosty: passkeys pozostają bardzo wartościowym mechanizmem ograniczającym skuteczność phishingu, lecz nie zastępują ochrony endpointów, monitoringu tożsamości i rygorystycznej walidacji po stronie usług. Wraz ze wzrostem adopcji tego rozwiązania rośnie też znaczenie jakości implementacji i szybkiego reagowania na błędy w całym ekosystemie.