Jak działa WebAuthn i klucze sprzętowe

Hasła mają poważny problem — większość ludzi używa tych samych kilku kombinacji na dziesiątkach serwisów, a wycieki baz danych zdarzają się regularnie. WebAuthn i klucze sprzętowe rozwiązują ten problem u podstaw, zastępując sekret, który można ukraść, kryptografią asymetryczną opartą na fizycznym urządzeniu. Zanim jednak sięgniemy po YubiKey lub skonfigurujemy passkeys w systemie operacyjnym, warto zrozumieć, co tak naprawdę dzieje się pod spodem.

Czym są WebAuthn klucze i skąd pochodzi ten standard

WebAuthn (Web Authentication API) to otwarty standard opracowany przez W3C i FIDO Alliance, który definiuje protokół silnego uwierzytelniania w przeglądarkach i aplikacjach. Wszedł w fazę rekomendacji W3C w 2019 roku i od tego momentu jest obsługiwany przez wszystkie główne przeglądarki — Chrome, Firefox, Safari i Edge. Standard ten jest częścią szerszego ekosystemu FIDO2, obok protokołu CTAP2 (Client-to-Authenticator Protocol), który reguluje komunikację między przeglądarką a fizycznym urządzeniem uwierzytelniającym.

Idea jest prosta, choć realizacja techniczna — nie. Zamiast wysyłać tajny ciąg znaków (hasło) do serwera, przeglądarka generuje wyzwanie kryptograficzne (ang. challenge), które urządzenie podpisuje prywatnym kluczem przechowywanym wyłącznie lokalnie. Serwer weryfikuje podpis kluczem publicznym, który zna. Nawet jeśli ktoś przechwyci całą tę komunikację, nie dostanie nic użytecznego — unikalny podpis do konkretnego wyzwania jest bezwartościowy przy następnym logowaniu.

Passkeys jako konsumencka twarz WebAuthn

Passkeys to marketingowe i użytkowe opakowanie dla tej samej technologii. Apple, Google i Microsoft wspólnie przyjęły tę nazwę, żeby ułatwić masowe wdrożenie. Z perspektywy protokołu passkey to po prostu poświadczenie WebAuthn z jedną istotną różnicą — para kluczy może być synchronizowana między urządzeniami przez chmurę producenta (iCloud Keychain, Google Password Manager, Windows Hello). Logowanie bez hasła staje się dzięki temu możliwe nawet po zmianie telefonu, co wcześniej było problemem przy dedykowanych kluczach sprzętowych.

Ważne zastrzeżenie: klucze synchronizowane przez chmurę oferują inny model bezpieczeństwa niż fizyczne tokeny. Są wygodniejsze, ale ich prywatna część opuszcza urządzenie — trafia do zaszyfrowanego sejfu producenta. Dla większości użytkowników to kompromis korzystny. Dla środowisk wymagających najwyższego poziomu ochrony, takich jak dostęp do infrastruktury krytycznej, lepszym wyborem pozostaje hardware-bound credential.

Jak przebiega rejestracja i logowanie w praktyce

Cały mechanizm WebAuthn składa się z dwóch faz: rejestracji i uwierzytelniania. Obie są starannie zaprojektowane tak, żeby eliminować typowe wektory ataku.

Podczas rejestracji serwer generuje losowe wyzwanie (co najmniej 16 bajtów entropii według specyfikacji) i przesyła je wraz z informacjami o swojej tożsamości — tzw. Relying Party ID, zazwyczaj domeną. Przeglądarka wywołuje API nawigatorowe navigator.credentials.create(), użytkownik potwierdza tożsamość (odciskiem palca, kodem PIN lub dotknięciem klucza sprzętowego), a urządzenie tworzy nową parę kluczy RSA lub EC (krzywa P-256). Klucz prywatny nigdy nie opuszcza urządzenia. Serwer zapisuje klucz publiczny, identyfikator poświadczenia i weryfikuje podpisaną deklarację.

Przy logowaniu sekwencja jest podobna: serwer wysyła wyzwanie, przeglądarka wywołuje navigator.credentials.get(), urządzenie podpisuje wyzwanie prywatnym kluczem, serwer weryfikuje podpis. Cały proces trwa kilkaset milisekund.

Ochrona przed phishingiem wbudowana w protokół

Jedną z najmocniejszych właściwości WebAuthn jest binding do domeny. Relying Party ID jest kryptograficznie powiązany z poświadczeniem — przeglądarka odmówi użycia klucza zarejestrowanego dla bank.pl przy próbie uwierzytelnienia na bańk.pl lub jakimkolwiek innym adresie. Nawet perfekcyjnie sklonowana strona phishingowa nie wyłudzi podpisu, bo domena się nie zgadza.

To fundamentalna różnica względem tradycyjnych haseł i nawet kodów TOTP, które użytkownik może wpisać na fałszywej stronie. FIDO2 eliminuje ten wektor ataku przez sam projekt protokołu — bez żadnych dodatkowych warstw edukacji użytkownika.

YubiKey i inne klucze sprzętowe — co je wyróżnia

YubiKey to najpopularniejszy klucz sprzętowy na rynku, produkowany przez szwedzką firmę Yubico od 2008 roku. Nowsze modele — YubiKey 5 i YubiKey Bio — obsługują FIDO2/WebAuthn, starszy protokół U2F, a dodatkowo OTP, PIV i OpenPGP. Interfejsy to USB-A, USB-C, NFC i Lightning, co pozwala dopasować urządzenie do komputera i telefonu jednocześnie.

Klucz sprzętowy działa inaczej niż passkeys synchronizowane w chmurze:

• Prywatny klucz jest generowany i przechowywany bezpośrednio w zabezpieczonym chipie (Secure Element) — nigdy nie wychodzi na zewnątrz urządzenia.
• Fizyczne potwierdzenie (dotknięcie złotego styku) jest wymagane przy każdym uwierzytelnieniu, co uniemożliwia atak zdalny.
• Urządzenie jest odporne na złośliwe oprogramowanie — nawet na zainfekowanym komputerze malware nie może wyodrębnić klucza prywatnego.
• Po 8 nieudanych próbach (dla trybu PIN FIDO2) urządzenie blokuje się, co utrudnia ataki brute-force przy fizycznym dostępie.
• Jeden klucz może przechować setki poświadczeń (YubiKey 5 obsługuje do 25 kluczy rezydentnych, a z kluczami per-serwer praktycznie nieograniczoną liczbę).

Głównym ograniczeniem jest scenariusz zgubienia lub uszkodzenia. Każda solidna strategia wdrożenia zakłada posiadanie co najmniej dwóch kluczy rejestrowanych równolegle do tych samych serwisów. Koszt jednego YubiKey 5 NFC wynosi około 50-60 euro, co przy skali korporacyjnej jest akceptowalną inwestycją w bezpieczeństwo.

Alternatywy to klucze Google Titan, Nitrokey (open source), Thetis czy OnlyKey. Różnią się obsługiwanymi protokołami, interfejsami i modelem otwartości oprogramowania sprzętowego.

Logowanie bez hasła — kto już to wdraża i jakie są ograniczenia

Logowanie bez hasła przestało być eksperymentem. Microsoft konta, Apple ID, Google Accounts, GitHub, Dropbox, Shopify, 1Password — lista serwisów z obsługą passkeys i WebAuthn rośnie co miesiąc. W 2023 roku Apple i Google włączyły synchronizację passkeys domyślnie, co otworzyło tę technologię na setki milionów użytkowników bez technicznego zaplecza.

Od strony wdrożeniowej implementacja WebAuthn po stronie serwera wymaga:

• Biblioteki serwerowej do weryfikacji poświadczeń (np. webauthn4j dla Javy, py_webauthn dla Pythona, SimpleWebAuthn dla Node.js)
• Obsługi bazy danych z informacją o publicznych kluczach i licznikach podpisów (sign counter, który pozwala wykryć sklonowane klucze)
• Logiki fallback — WebAuthn nie działa na wszystkich przeglądarkach mobilnych w trybie PWA, nie działa bez HTTPS, i wymaga świadomego UX na etapie rejestracji

Obsługa przez przeglądarki jest dziś niemal powszechna, ale wciąż zdarzają się wyjątki. Tryb prywatny w niektórych wersjach przeglądarek mobilnych ogranicza dostęp do API. Aplikacje webowe osadzone w natywnych kontenerach (np. iOS WebView bez konfiguracji ASWebAuthenticationSession) mogą nie mieć dostępu do systemu zarządzania kluczami.

Przejście z haseł na WebAuthn w organizacji

Migracja nie musi być natychmiastowa. Skuteczne podejście to stopniowe wdrożenie: WebAuthn jako drugi składnik uwierzytelniania (2FA), potem opcja logowania bez hasła przy zachowaniu hasła jako fallback, docelowo wymuszone logowanie bez hasła dla grup wysokiego ryzyka — administratorów, deweloperów, pracowników działów finansowych.

Szkolenie użytkowników to często niedoceniany element. Rejestracja klucza sprzętowego lub passkey różni się od zwykłego zapisania hasła w menedżerze — wymaga jednorazowego fizycznego gestu lub zatwierdzenia biometrycznego. Użytkownicy, którzy rozumieją, dlaczego ta czynność jest potrzebna, rzadziej ją omijają lub szukają backdoorów.

Bezpieczeństwo WebAuthn — co chroni, a czego nie

WebAuthn eliminuje całą kategorię ataków opartych na wykradaniu tajemnic: phishing poświadczeń, credential stuffing, ataki na bazy haseł, przechwytywanie pakietów. To znacząca redukcja powierzchni ataku.

Nie eliminuje jednak wszystkich zagrożeń. Model zagrożeń wart rozważenia obejmuje:

• Ataki na endpoint — urządzenie użytkownika zainfekowane malware może nie wykraść klucza prywatnego, ale może poczekać na moment, gdy użytkownik sam wykona uwierzytelnienie i przejąć sesję już po jej utworzeniu.
• Inżynierię społeczną — techniki manipulacji mogą skłonić użytkownika do zatwierdzenia transakcji, której nie chciał zatwierdzić.
• Utratę urządzenia — bez procedury odzyskiwania konta użytkownik zostaje zablokowany. Dobre serwisy implementują awaryjne kody jednorazowe lub możliwość rejestracji zapasowego poświadczenia.

Ogólny poziom bezpieczeństwa WebAuthn pozostaje znacznie wyższy niż haseł i kodów SMS. NIST w wytycznych SP 800-63B (aktualizacja 2024) wskazuje uwierzytelnianie sprzętowe oparte na kryptografii jako AAL3 — najwyższy poziom pewności uwierzytelniania. To samo poświadczenie z synchronizacją w chmurze osiąga AAL2.

Dla większości zastosowań konsumenckich passkeys w chmurze to bardzo dobry wybór, oferujący radykalne uproszczenie logowania przy akceptowalnym poziomie ryzyka. Dla środowisk korporacyjnych z wrażliwymi danymi, wymaganiami regulacyjnymi lub modelem Zero Trust — dedykowane klucze sprzętowe jak YubiKey zapewniają warunki, których chmura nie gwarantuje. Wybór między tymi podejściami to inżynierska decyzja o modelu zagrożeń, nie kwestia preferencji estetycznych.

Redakcja

Za Foto5 stoi redakcja, która dostarcza konkretne porady i inspiracje z różnych obszarów życia – od nowoczesnych technologii po dom, ogród, zdrowie i finanse. Nasze artykuły pomagają podejmować lepsze decyzje na co dzień.