Funkcjonalność

Wyciekłe hasła (Breached password detection)

Jak działa: Odrzuca hasła, które już wyciekły w innych incydentach.

CIC

W skrócie

Wielu klientów używa tego samego hasła w kilku serwisach. Gdy jedno z nich zostaje zhakowane, atakujący próbują wyciekłych haseł na wielu publicznych aplikacjach. Wykrywanie wyciekłych haseł w Auth0 oznacza takie logowania i może je zablokować lub powiadomić użytkownika. Sprawdzenie korzysta z danych o wyciekach, które utrzymuje Auth0.12

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

Co to jest i jakie ataki zatrzymuje

Wielu klientów używa tego samego hasła w kilku serwisach. Gdy jedno z nich zostaje zhakowane, wyciekłe hasło staje się gotowym kluczem do każdego innego konta, na którym klient to hasło powtórzył.

Wykrywanie wyciekłych haseł porównuje hasło użyte przy logowaniu lub zmianie hasła z danymi z publicznych źródeł o wyciekach/incydentach. Ważne: samo z siebie nie skanuje każdego hasła zapisanego w Twoim katalogu.1

To pomaga przy atakach, takich jak:

1

Credential stuffing

Atakujący testują losowe wyciekłe pary adresu e-mail i hasła na Twojej stronie logowania.

2

Celowane przejęcie konta

Atakujący szuka konkretnego klienta w wyciekłych danych i loguje się do Twojej aplikacji hasłem, które tam znalazł.

3

Popularne hasła, które pojawiają się w wielu wyciekach

Hasła, które pojawiają się w wielu wyciekach, to te, których atakujący próbują w pierwszej kolejności.

4

Przejęcia, które wyglądają jak zwykłe logowania

Atakujący wpisuje poprawne hasło, więc nic w procesie logowania nie wygląda podejrzanie.

Przed i po wdrożeniu funkcjonalności

Przed
Po
PrzedWyciekłe hasło działa w Twoim serwisie, dopóki klient przypadkiem go nie zmieni.
PoLogowanie hasłem, które wyciekło, można zablokować - a klienta powiadomić.1
PrzedPierwszym sygnałem wycieku hasła jest przejęcie konta.
PoLogowanie z użyciem wyciekłych danych można zablokować, zanim zamieni się w przejęcie konta.1
PrzedTwój zespół dowiaduje się o wyciekach dopiero wtedy, gdy klient się poskarży.
PoOznaczone logowania można przejrzeć w dashboardzie Auth0, więc zespół widzi je bez czekania na zgłoszenie.1
PrzedKażdy klient musi sam ocenić, czy jego hasło jest bezpieczne.
PoSprawdzenie odbywa się przy logowaniu, więc klient nie musi wiedzieć, czy hasło wyciekło.1

Jak to robi Auth0

Auth0 Breached Password Detection działa przy logowaniu, a Ty wybierasz, co ma się stać, gdy znajdzie dopasowanie.1

1

Klient loguje się

Klient wpisuje adres e-mail i hasło na stronie logowania opartej na Auth0.1

2

Auth0 porównuje dane logowania

Auth0 sprawdza, czy dane pasują do tych, które wyciekły w incydencie w innych serwisach.1

3

Auth0 reaguje zgodnie z konfiguracją

W zależności od ustawień, Auth0 może zareagować na przykład blokadą logowania albo powiadomieniem użytkownika.1

4

Klient ustawia nowe hasło

Klient wybiera potem nowe hasło, zwykle przez standardowy proces resetu hasła.4

CIC
Kogo chroniUżytkownicy Twojej aplikacji
Breached Password DetectionAuth0 Attack Protection zawiera wykrywanie wyciekłych haseł. Sprawdza dane logowania w momencie uwierzytelniania względem danych o wyciekach.12
Konfigurowalna reakcjaMożesz wybrać reakcje, takie jak blokada logowania albo powiadomienie użytkownika.1
Ustawienia siły hasłaPołączenia typu database connections w Auth0 oferują ustawienia polityki haseł, które wyznaczają minimalne reguły dla nowych haseł.4
PasskeysPołączenia typu database connections w Auth0 obsługują passkeys, więc klient w ogóle nie potrzebuje hasła wielokrotnego użytku.3

Jak wdrażamy to w Zelto

Wykrywanie zapewnia Auth0 - Zelto ustala z Tobą, co dzieje się po dopasowaniu, żeby ochrona nie zamieniła się w falę telefonów do supportu. Zaczynamy od tego, jak Twoi klienci logują się i resetują hasła dziś. Planujemy zmianę etapami, aby zminimalizować ryzyko i skutki, i dbamy o proces odzyskiwania dostępu, którego atakujący nie obejdzie szybką rozmową.

Typowy przebieg wdrożenia

  1. Sprawdzamy, jak klienci logują się i odzyskują dostęp

    Spisujemy Twoje procesy logowania, połączenia typu database connections w Auth0 i ścieżki resetu hasła.

  2. Wybieramy reakcję

    Dla każdego procesu ustalamy, czy dopasowanie blokuje logowanie, powiadamia klienta czy jedno i drugie, oraz kto po Twojej stronie jest odpowiedzialny za późniejsze zmiany w tym procesie.

  3. Przygotowujemy komunikat dla klienta i proces odzyskiwania dostępu

    Piszemy powiadomienie i kroki resetu tak, aby zablokowany klient wiedział, co zrobić. Proces resetu hasła weryfikuje tożsamość klienta, zanim przyjmie nowe hasło.

  4. Włączamy etapami

    Najpierw włączamy ochronę w środowisku testowym, potem na produkcji, grupa po grupie. Zanim zaostrzymy jakiekolwiek ustawienie, obserwujemy liczbę oznaczonych logowań.

  5. Przeglądamy i przechodzimy na passkeys

    Oznaczone logowania przeglądamy regularnie. Tam, gdzie to ma sens, nakłaniamy klientów do przejścia na passkeys, aby w ogóle nie posiadali hasła wielokrotnego użytku, które mogłoby wyciec.

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

Klient loguje się hasłem, które pojawiło się w wycieku.

−Blokujemy logowanie ogólnym błędem, bez wyjaśnienia. Klient dzwoni do supportu albo odchodzi.

+Blokujemy lub oznaczamy logowanie, mówimy klientowi dlaczego i kierujemy go do resetu hasła.

Zablokowany klient prosi o reset hasła.

−Wysyłamy link do resetu na każdy adres na życzenie, bez sprawdzenia, kto o niego prosi.

+Wysyłamy reset tylko na zweryfikowany adres przypisany do konta i wymagamy nowego hasła, którego nie ma na liście wycieków.

Wielu obecnych klientów używa wyciekłych haseł, a ochrona jest włączana dla wszystkich tego samego dnia.

−Duża grupa zostaje zablokowana naraz, a support jest przeciążony.

+Włączamy etapami, dajemy supportowi instrukcję dla każdej grupy i ustalamy dogodne daty dla każdej z nich.

Wykrywanie wyciekłych haseł jest jedyną ochroną na stronie logowania.

−Klienta z unikalnym hasłem uznajemy za bezpiecznego, a zautomatyzowane ataki i zgadywanie haseł pozostają niezauważone.

+Łączymy je z wykrywaniem botów i ograniczaniem ruchu z adresów IP oraz oferujemy passkeys, aby żadna pojedyncza kontrola nie odpowiadała za całe ryzyko logowania.

Chcesz, żeby wyciekłe hasła przestały otwierać konta klientów?

Sprawdzimy, jak dziś Twoi klienci logują się i resetują hasła. Potem powiemy, od czego zacząć.

Umów rozmowę30 minut, bez prezentacji. Sprawdzamy dzisiejsze procesy logowania Twoich klientów.

Powiązane wpisy na blogu

Notatki z wdrożeń

C Is For Credentials: Practical Hygiene and Secrets ManagementCzytaj na blogu →H Is For Hashing: Elevating Identity Security Beyond Basic PasswordsCzytaj na blogu →

Źródła

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

  1. 1Breached password detectionAuth0 Docs
  2. 2Attack protectionAuth0 Docs
  3. 3Passkeys in Auth0 database connectionsAuth0 Docs
  4. 4Password strength in database connectionsAuth0 Docs