Funkcjonalność

Passkeys

Jak działa: Używając passkeys, logowanie nie opiera się na haśle wielokrotnego użytku, które atakujący mógłby ukraść lub wyłudzić.

CIC

W skrócie

Passkeys pozwalają klientom logować się kluczem zapisanym na ich urządzeniu zamiast hasłem. Klucz jest powiązany z domeną Twojej strony, więc fałszywa strona nie dostaje niczego, co mogłaby użyć. Połączenia bazodanowe (database connections) w Auth0 obsługują passkeys.1

Umów rozmowęJak to robi Auth0 ↓
5
rodzajów ataków, przed którymi pomaga chronić

Co to jest i jakie ataki zatrzymuje

Hasło to sekret, który zna Twój klient, Twój system przechowuje jego zaszyfrowaną wersję, a atakujący może próbować zdobyć go z obu stron. Klienci często też używają tego samego hasła w wielu serwisach.

Passkeys działają inaczej - przypisane do urządzenia trzymają klucz prywatny na urządzeniu klienta, a urządzenie używa go tylko dla domeny strony, dla której klucz utworzono.1

Art. 21 ust. 2 lit. j dyrektywy NIS2 wymienia stosowanie uwierzytelniania wieloskładnikowego lub ciągłego uwierzytelniania wśród środków zarządzania ryzykiem cyberbezpieczeństwa.5

Usunięcie hasła wielokrotnego użytku zatrzymuje ataki, takie jak:

1

Wyłudzanie haseł (phishing)

Fałszywa strona logowania zbiera hasło wpisane przez klienta. Używając passkeys nie ma hasła do wpisania, więc fałszywa strona nie ma niczego, co mogłaby odtworzyć.

2

Credential stuffing

Atakujący testują losowe wyciekłe pary adresu e-mail i hasła na Twojej stronie logowania. Przy logowaniu z passkey nie ma hasła, więc taki atak jest niemożliwy.

3

Powtarzane hasła

Klient używa tego samego hasła w Twoim serwisie i w mniejszym serwisie, który padł ofiarą wycieku. Passkey powstaje tylko dla Twojej strony, więc nie ma czego przenieść.

4

Password spraying i zgadywanie haseł

Atakujący próbują popularnych haseł na wielu kontach, ale konta logujące się poprzez passkeys nie posiadają haseł do odgadnięcia.

5

Wycieki baz haseł

Wyciek bazy ujawnia hasła klientów. System z passkeys przechowuje klucz, który nie pozwala atakującemu się zalogować samym ujawnionym hasłem.

Przed i po wdrożeniu funkcjonalności

Przed
Po
PrzedHasło klienta z wycieku w innym serwisie otwiera jego konto w Twoim serwisie.
PoHasło z wycieku w innym serwisie już nie wystarcza, bo klient nie ma możliwości zalogowania się bez passkey.1
PrzedFałszywa strona logowania zbiera to, co wpisze klient.
PoPasskey odpowiada tylko domenie strony, dla której powstał, więc fałszywa strona nie dostaje niczego.
PrzedKlienci zapominają hasła, a resetowanie haseł obciąża wsparcie i otwiera kolejny potencjalny wektor ataku.
PoKlienci logują się biometrią lub PIN-em na swoim urządzeniu, więc potrzeba mniej resetów haseł.
PrzedBezpieczeństwo zależy od tego, czy klient wybierze silne, unikalne hasło.
PoKlucz jest tworzony przez urządzenie - klient nie musi niczego wybierać ani pamiętać.

Jak to robi Auth0

Auth0 obsługuje passkeys w połączeniach bazodanowych (database connections), a klucze bezpieczeństwa WebAuthn można dodać jako faktor MFA.

1

Klient zaczyna logowanie

Klient otwiera stronę logowania Twojej aplikacji, obsługiwaną przez Auth0.4

2

Klient wybiera passkey

Zamiast wpisywać hasło, klient wybiera logowanie za pomocą passkey.1

3

Urządzenie potwierdza obecność klienta

Urządzenie podpisuje żądanie kluczem prywatnym. Klient potwierdza na urządzeniu, na przykład biometrią lub PIN-em.1

4

Auth0 weryfikuje i loguje klienta

Auth0 sprawdza podpisaną odpowiedź względem passkey zarejestrowanego dla konta i akceptuje logowanie.1

Fałszywa strona

UżytkownikFałszywa strona✕ Wynik

Prawdziwe logowanie Auth0

UżytkownikAuth0✓ Wynik
CIC
Kogo chroniUżytkownicy Twojej aplikacji
PasskeysPołączenia bazodanowe (database connections) w Auth0 obsługują passkeys, więc klienci mogą logować się w pełni bez wielokrotnego hasła.1
Klucze WebAuthn jako faktor MFAKlucze bezpieczeństwa WebAuthn też można włączyć jako faktor MFA dla logowań klientów.2
Uwierzytelnianie wieloskładnikoweAuth0 udostępnia opcje MFA, które można łączyć z innymi metodami logowania w Twoim środowisku Auth0.3
Universal LoginAuth0 Universal Login to hostowane środowisko logowania, w którym klienci się uwierzytelniają.4

Jak wdrażamy to w Zelto

Technologia za Auth0 to gotowa i sprawdzona połowa - Zelto planuje, jak Twoi klienci przechodzą z haseł na passkeys. Wdrażamy etapami, aby zminimalizować ryzyko i skutki dla rejestracji, logowania i wsparcia. Dbamy też o proces odzyskiwania dostępu, którego atakujący nie obejdzie szybką rozmową.

Typowy przebieg wdrożenia

  1. Sprawdzamy, jak klienci logują się dziś

    Spisujemy aplikacje, połączenia, metody logowania i urządzenia, z których korzystają klienci.

  2. Decydujemy, gdzie pasują passkeys

    Wybieramy, w których ścieżkach klienta oferujemy passkeys najpierw, i czy zastępują hasło, czy działają obok niego. Do tego używamy database connections w Auth0.

  3. Pilotaż na małej grupie klientów

    Zaczynamy od ograniczonej grupy lub jednej aplikacji, ustalamy właściciela po Twojej stronie. Ustalamy też, kiedy rozszerzamy zakres i pod jakimi warunkami go wycofujemy (roll-back).

  4. Przygotowujemy wsparcie i odzyskiwanie dostępu

    Spisujemy kroki odzyskiwania dostępu po zgubieniu lub wymianie urządzenia. Zespół wsparcia dostaje odpowiedzi na potencjalne pytania klientów.

  5. Rozszerzamy zakres i ograniczamy hasła

    Zachęcamy do rejestracji passkeys i ograniczamy zależność od haseł, gdy to tylko możliwe. Metody zapasowe przeglądamy regularnie.

Pułapki, które uwzględniamy w planie

Klient gubi telefon, na którym ma passkey.

−Wpuszczamy klienta linkiem e-mail lub kodem SMS, z którego może skorzystać każdy, kto ma dostęp do skrzynki lub karty SIM.

+Oferujemy proces odzyskiwania dostępu, który weryfikuje tożsamość klienta, a potem prosimy o rejestrację nowego passkey.

Klienci logują się z kilku urządzeń i przeglądarek.

−Oferujemy passkey tylko na pierwszym urządzeniu, więc na każdym innym klienci wracają do hasła.

+Zachęcamy do dodania passkey na każdym używanym urządzeniu i testujemy ścieżkę na przeglądarkach i urządzeniach, które klienci faktycznie mają.

Passkeys są dodane obok istniejących haseł.

−Hasła zostają w pełni aktywne na zawsze, więc atakujący nadal celują w tę drogę.

+Z czasem ograniczamy użycie haseł, w miarę jak rośnie rejestracja passkeys, i regularnie przeglądamy pozostałe wyjątki.

Klient dostaje prośbę o utworzenie passkey bez wyjaśnienia.

−Pokazujemy techniczny komunikat, którego klienci nie rozumieją, po czym zamykają stronę i nigdy nie rejestrują swojego passkey.

+Wyjaśniamy jednym prostym zdaniem, po co i kiedy utworzyć passkey, i proponujemy to zaraz po udanym logowaniu klienta.

Passkey synchronizuje się na każde urządzenie w koncie chmurowym klienta.

−Traktujemy zsynchronizowane passkeys jak w pełni odporne na phishing, choć każdy, kto ma dostęp do konta chmurowego, może zarejestrować ten sam passkey gdzie indziej.

+Decydujemy, w których ścieżkach klienta dopuszczamy synchronizowane passkeys, wymagamy drugiego faktora tam, gdzie ryzyko jest wyższe, i zostawiamy proces odzyskiwania, który nie opiera się wyłącznie na e-mailu lub SMS-ie.

Chcesz, aby klienci logowali się bez haseł i bez wdrożenia, które utknie w połowie?

Sprawdzimy, jak dziś logują się Twoi klienci. Potem powiemy, gdzie najpierw pasują passkeys.

Umów rozmowę30 minut, bez prezentacji. Sprawdzamy, jak dziś logują się Twoi klienci.

Powiązane wpisy na blogu

Notatki z wdrożeń

F is for FIDO2Czytaj na blogu →B is for Biometrics: Hardening Identity with Hardware-Backed VerificationCzytaj na blogu →W Is For WebAuthn: Primary Passwordless LayerCzytaj na blogu →

Źródła

Oficjalna dokumentacja Okta i Auth0 oraz źródła prawne

  1. 1Passkeys in Auth0 database connectionsAuth0 Docs
  2. 2Configure WebAuthn security keys as an MFA factorAuth0 Docs
  3. 3Multi-factor authenticationAuth0 Docs
  4. 4Auth0 Universal LoginAuth0 Docs
  5. 5Directive (EU) 2022/2555 (NIS2)EUR-Lex