WebAuthn — WebAuthn
Uwierzytelnianie sieci Web ( WebAuthn ) to standard sieciowy opublikowany przez konsorcjum World Wide Web Consortium (W3C). WebAuthn jest podstawowym elementem projektu FIDO2 pod przewodnictwem FIDO Alliance . Celem projektu jest standaryzacja interfejsu do uwierzytelniania użytkowników w aplikacjach i usługach internetowych z wykorzystaniem kryptografii klucza publicznego .
Po stronie klienta wsparcie dla WebAuthn można zaimplementować na różne sposoby. Podstawowe operacje kryptograficzne są wykonywane przez Authenticator , który jest abstrakcyjnym modelem funkcjonalnym, który jest w większości niezależny od sposobu zarządzania materiałem klucza. Umożliwia to wdrożenie obsługi WebAuthn wyłącznie w oprogramowaniu, wykorzystując zaufane środowisko wykonawcze procesora lub moduł Trusted Platform Module (TPM). Wrażliwe operacje kryptograficzne można również przenieść do mobilnego uwierzytelniacza sprzętowego, do którego z kolei można uzyskać dostęp za pośrednictwem USB , Bluetooth Low Energy lub komunikacji bliskiego zasięgu (NFC). Urządzenie uwierzytelniające w roamingu jest zgodne z protokołem FIDO Client to Authenticator Protocol (CTAP), dzięki czemu WebAuthn jest skutecznie wstecznie kompatybilny ze standardem FIDO Universal 2nd Factor (U2F).
Podobnie jak w przypadku starszego U2F, uwierzytelnianie internetowe jest odporne na podszywanie się pod weryfikatora, co oznacza, że jest odporne na aktywne ataki typu man-in-the-middle, ale w przeciwieństwie do U2F, WebAuthn nie wymaga tradycyjnego hasła. Co więcej, uwierzytelnianie sprzętowe w roamingu jest odporne na złośliwe oprogramowanie, ponieważ materiał klucza prywatnego nie jest w żadnym momencie dostępny dla oprogramowania uruchomionego na komputerze hosta.
Standard WebAuthn Level 1 został opublikowany jako zalecenie W3C w dniu 4 marca 2019 r. Specyfikacja dla poziomu 2 jest w trakcie opracowywania.
Tło
FIDO2 jest następcą starszego protokołu FIDO Universal 2nd Factor (U2F). Uwierzytelnianie FIDO2 ma wszystkie zalety U2F — podstawowa różnica polega na tym, że uwierzytelnianie FIDO2 może być również pojedynczym uwierzytelniaczem wieloskładnikowym (bez hasła). Protokół U2F ma działać jako drugi czynnik wzmacniający istniejące przepływy logowania oparte na nazwie użytkownika/hasłach.
Uwierzytelniacz FIDO2 może być używany w trybie jednoczynnikowym lub wieloczynnikowym. W trybie jednoczynnikowym uwierzytelnianie jest aktywowane przez test obecności użytkownika, który zwykle składa się z prostego naciśnięcia przycisku. W trybie wieloskładnikowym wystawca uwierzytelnienia ( coś, co masz ) przeprowadza weryfikację użytkownika. W zależności od możliwości uwierzytelniania może to być:
- coś, co wiesz: sekret, taki jak PIN , hasło lub wzór swipe
- coś jesteś: biometrycznych , takich jak linii papilarnych, tęczówki lub głosem
W każdym przypadku uwierzytelniający przeprowadza weryfikację użytkownika lokalnie na urządzeniu. Sekret lub dane biometryczne przechowywane w uwierzytelniaczu nie są udostępniane stronie internetowej. Co więcej, ze wszystkimi stronami internetowymi działa jeden klucz tajny lub biometryczny, ponieważ osoba uwierzytelniająca wybierze właściwy materiał klucza kryptograficznego, który będzie używany dla usługi żądającej uwierzytelnienia po pomyślnym zakończeniu weryfikacji użytkownika.
Sekret i dane biometryczne w uwierzytelniaczu mogą być używane razem, podobnie jak w smartfonie . Na przykład odcisk palca służy do zapewnienia wygodnego dostępu do smartfona, ale czasami dostęp do odcisku palca kończy się niepowodzeniem, w którym to przypadku można użyć kodu PIN.
Przegląd
Podobnie jak jego poprzednik FIDO U2F, uwierzytelnianie sieci W3C (WebAuthn) obejmuje witrynę internetową , przeglądarkę internetową i uwierzytelnianie:
- Witryna jest zgodną stroną ufającą WebAuthn
- Przeglądarka jest zgodnym klientem WebAuthn
- Uwierzytelniacz jest uwierzytelniaczem FIDO2, to znaczy zakłada się, że jest zgodny z klientem WebAuthn
WebAuthn określa, w jaki sposób strona wnosząca roszczenie demonstruje posiadanie i kontrolę modułu uwierzytelniającego FIDO2 weryfikatorowi zwanemu Stroną Ufającą WebAuthn. Proces uwierzytelniania odbywa się za pośrednictwem jednostki zwanej klientem WebAuthn, która jest niewiele więcej niż zgodną przeglądarką internetową.
Uwierzytelnianie
Na potrzeby ilustracji zakładamy, że wystawca uwierzytelnienia jest urządzeniem uwierzytelniającym sprzęt mobilny (zobacz poniżej inne opcje). W każdym razie wystawca uwierzytelnienia jest wieloskładnikowym uwierzytelniaczem kryptograficznym, który używa kryptografii klucza publicznego do podpisania potwierdzenia uwierzytelniania skierowanego do strony ufającej WebAuthn. Zakładając, że uwierzytelniający używa kodu PIN do weryfikacji użytkownika, sam uwierzytelniający jest czymś, co masz, podczas gdy kod PIN jest czymś, co znasz .
Aby zainicjować przepływ uwierzytelniania WebAuthn, strona uzależniona WebAuthn wskazuje swoje intencje klientowi WebAuthn (tj. przeglądarce) za pośrednictwem JavaScript . Klient WebAuthn komunikuje się z uwierzytelniającym za pomocą JavaScript API zaimplementowanego w przeglądarce. Uwierzytelniacz mobilny jest zgodny z protokołem FIDO Client to Authenticator Protocol .
WebAuthn nie wymaga bezwzględnie mobilnego uwierzytelnienia sprzętowego. Alternatywnie, można zastosować program uwierzytelniający (zaimplementowany na przykład na smartfonie) lub uwierzytelniający platformę (tj. uwierzytelniający zaimplementowany bezpośrednio na urządzeniu klienckim WebAuthn). Odpowiednie przykłady narzędzi uwierzytelniających platformy obejmują Windows Hello i system operacyjny Android .
Przedstawiony przepływ opiera się na weryfikacji użytkownika na podstawie kodu PIN, co pod względem użyteczności jest tylko skromnym ulepszeniem w porównaniu ze zwykłym uwierzytelnianiem hasłem. W praktyce wykorzystanie biometrii do weryfikacji użytkowników może poprawić użyteczność WebAuthn. Logistyka stojąca za biometrią jest jednak nadal słabo poznana. Wśród użytkowników utrzymuje się nieporozumienie, że dane biometryczne są przesyłane przez sieć w taki sam sposób, jak hasła, a tak nie jest.
Rejestracja
Gdy strona uzależniona WebAuthn odbiera podpisane potwierdzenie uwierzytelniania z przeglądarki, podpis cyfrowy potwierdzenia jest weryfikowany przy użyciu zaufanego klucza publicznego dla użytkownika. W jaki sposób strona ufająca WebAuthn uzyskuje zaufany klucz publiczny?
Aby uzyskać klucz publiczny dla użytkownika, strona uzależniona WebAuthn inicjuje przepływ rejestracji WebAuthn, który jest bardzo podobny do przepływu uwierzytelniania przedstawionego powyżej. Podstawowa różnica polega na tym, że osoba uwierzytelniająca podpisuje teraz oświadczenie atestacji swoim kluczem prywatnym atestacji. Podpisana instrukcja atestacji zawiera kopię klucza publicznego, którego strona ufająca WebAuthn ostatecznie używa do weryfikacji podpisanego potwierdzenia uwierzytelniania. Oświadczenie atestacyjne zawiera również metadane opisujące samego wystawcę uwierzytelnienia.
Podpis cyfrowy na oświadczeniu poświadczenia jest weryfikowany za pomocą zaufanego klucza publicznego poświadczenia dla tego konkretnego modelu uwierzytelniania. Sposób, w jaki strona ufająca WebAuthn uzyskuje swój magazyn zaufanych kluczy publicznych atestacji, jest nieokreślony. Jedną z opcji jest skorzystanie z usługi metadanych FIDO.
Typ poświadczenia określony w JavaScript określa model zaufania. Na przykład może być pożądany typ poświadczenia zwany samopoświadczeniem, dla którego model zaufania jest zasadniczo zaufaniem przy pierwszym użyciu .
Wsparcie
Standard WebAuthn Level 1 został opublikowany jako rekomendacja W3C przez Grupę Roboczą ds. Uwierzytelniania Sieciową w dniu 4 marca 2019 r. WebAuthn jest obsługiwany przez następujące przeglądarki internetowe: Google Chrome , Mozilla Firefox , Microsoft Edge , Apple Safari i przeglądarka internetowa Opera .
Komputerowa wersja przeglądarki Google Chrome obsługuje WebAuthn od wersji 67. Firefox, który nie w pełni obsługiwał poprzedni standard FIDO U2F, dołączył i umożliwił WebAuthn w przeglądarce Firefox w wersji 60, wydanej 9 maja 2018 r. Wczesna wersja Microsoft Edge dla Windows Insider (Kompilacja 17682) zaimplementowała wersję WebAuthn, która działa zarówno z Windows Hello, jak i z zewnętrznymi kluczami bezpieczeństwa.
Istniejące klucze bezpieczeństwa FIDO U2F są w dużej mierze zgodne ze standardem WebAuthn, chociaż WebAuthn dodał możliwość odwoływania się do unikalnego identyfikatora „obsługi użytkownika” na konto, którego starsze uwierzytelniające nie mogą przechowywać. Jednym z pierwszych uwierzytelniających zgodnych z FIDO2 był klucz bezpieczeństwa drugiej generacji firmy Yubico, ogłoszony 10 kwietnia 2018 r.
Pierwszy klucz FIDO2 z certyfikatem poziomu bezpieczeństwa 2, zwany „Goldengate”, został ogłoszony rok później przez eWBM 8 kwietnia 2019 r. i
Dropbox ogłosił wsparcie dla logowania WebAuthn (jako drugi czynnik) 8 maja 2018 r.
Apple Safari ogłosiło, że Face ID lub Touch ID mogą być używane jako uwierzytelnianie platformy WebAuthn 24 czerwca 2020 r.
API
WebAuthn implementuje rozszerzenie bardziej ogólnego interfejsu API zarządzania poświadczeniami W3C , który jest próbą sformalizowania interakcji między witrynami internetowymi a przeglądarkami internetowymi podczas wymiany poświadczeń użytkownika. Interfejs API uwierzytelniania w sieci Web rozszerza metody zarządzania poświadczeniami i JavaScript , dzięki czemu akceptują parametr. Metoda służy do rejestracji klucz publiczny uwierzytelniające jako część skojarzenie ich z kontami użytkowników (ewentualnie przy początkowym momencie tworzenia konta, ale bardziej prawdopodobne podczas dodawania nowego urządzenia zabezpieczającego do istniejącego konta), podczas gdy metoda jest używana do uwierzytelniania (na przykład podczas rejestrowania w).
navigator.credentials.create()navigator.credentials.get() publicKeycreate()get()
Aby sprawdzić, czy przeglądarka obsługuje WebAuthn, skrypty powinny sprawdzić, czy window.PublicKeyCredentialinterfejs jest zdefiniowany. Oprócz PublicKeyCredential, standard definiuje również interfejsy AuthenticatorResponse, AuthenticatorAttestationResponse, i oraz AuthenticatorAssertionResponseróżne słowniki i inne typy danych.
Interfejs API nie umożliwia bezpośredniego dostępu do kluczy prywatnych ani manipulowania nimi, poza żądaniem ich początkowego utworzenia.
Przyjęcie
W sierpniu 2018 Paragon Initiative Enterprises przeprowadziła audyt bezpieczeństwa standardu WebAuthn. Chociaż nie mogli znaleźć żadnych konkretnych exploitów, ujawnili kilka poważnych słabości w sposobie, w jaki podstawowa kryptografia jest wykorzystywana i nakazana przez standard.
Główne punkty krytyki dotyczą dwóch potencjalnych problemów, które były problematyczne w innych systemach kryptograficznych w przeszłości i dlatego należy ich unikać, aby nie paść ofiarą ataków tej samej klasy:
- Poprzez obowiązkowe użycie COSE (RFC 8152) WebAuthn obsługuje również RSA z dopełnieniem PKCS1v1.5 . Wiadomo, że ten konkretny schemat wypełniania jest podatny na określone ataki od co najmniej dwudziestu lat i w przeszłości był skutecznie atakowany w innych protokołach i implementacjach kryptosystemu RSA. Jest to trudne do wykorzystania w danych warunkach w kontekście WebAuthn, ale biorąc pod uwagę, że istnieją bezpieczniejsze prymitywy kryptograficzne i schematy wypełniania, jest to nadal zły wybór i nie jest już uważany za najlepszą praktykę wśród kryptografów.
- FIDO Alliance standaryzuje asymetryczny schemat kryptograficzny ECDAA . Jest to wersja bezpośredniego anonimowego poświadczania opartego na krzywych eliptycznych i w przypadku WebAuthn ma służyć do weryfikacji integralności uwierzytelniających, przy jednoczesnym zachowaniu prywatności użytkowników, ponieważ nie pozwala na globalną korelację uchwytów. Jednak ECDAA nie uwzględnia niektórych lekcji, które wyciągnięto w ostatnich dziesięcioleciach badań w dziedzinie kryptografii krzywych eliptycznych , ponieważ wybrana krzywa ma pewne braki bezpieczeństwa nieodłącznie związane z tego typu krzywą, co znacznie zmniejsza gwarancje bezpieczeństwa. Ponadto standard ECDAA obejmuje losowe, niedeterministyczne sygnatury, co już stanowiło problem w przeszłości.
Firma Paragon Initiative Enterprises skrytykowała również sposób, w jaki standard został pierwotnie opracowany, ponieważ propozycja nie została z wyprzedzeniem upubliczniona, a doświadczeni kryptolodzy nie byli proszeni o sugestie i opinie. Stąd standard nie był przedmiotem szerokich badań kryptograficznych ze świata akademickiego.
Pomimo tych niedociągnięć Paragon Initiative Enterprises nadal zachęca użytkowników do dalszego korzystania z WebAuthn, ale przedstawiło pewne zalecenia dla potencjalnych implementatorów i deweloperów standardu, które mają nadzieję zostać zaimplementowane przed sfinalizowaniem standardu. Unikanie takich błędów tak wcześnie, jak to możliwe, zapobiegłoby wszelkim wyzwaniom, jakie niosą ze sobą złamane standardy i konieczność wstecznej kompatybilności .
ECDAA został zaprojektowany wyłącznie w połączeniu z atestem urządzenia. Ta szczególna funkcja WebAuthn nie jest koniecznie wymagana do działania uwierzytelniania. Obecne implementacje pozwalają użytkownikowi decydować, czy podczas ceremonii rejestracji wysyłane jest oświadczenie atestacyjne. Niezależnie, strony ufające mogą zdecydować, czy chcą wymagać zaświadczenia, czy nie. ECDAA zostało usunięte z WebAuthn Level 2, ponieważ nie zostało zaimplementowane przez przeglądarki ani strony ufające.