Funkcjonalność

MFA odporne na phishing

Jak działa: Atakujący nie wykorzysta hasła, kodu ani sekretu, które wyłudzi od użytkownika.

WICCIC

W skrócie

MFA odporne na phishing loguje użytkownika kluczem zapisanym na jego urządzeniu. Klucz działa tylko na prawdziwej stronie. Fałszywa strona nie dostaje niczego, czego mogłaby użyć.12

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

Co to jest i jakie ataki zatrzymuje

Większość MFA nadal każe użytkownikowi coś przekazać. To może być hasło, sześciocyfrowy kod albo kliknięcie w powiadomieniu push. Atakujący może wyłudzić każde z nich od użytkownika.

MFA odporne na phishing działa inaczej. Dowód tożsamości zostaje na urządzeniu użytkownika. Urządzenie wysyła go tylko prawdziwej stronie, z którą dowód został powiązany.12

Ta jedna zmiana zatrzymuje ataki, takie jak:

1

Wyłudzanie haseł (phishing)

Fałszywa strona logowania zbiera hasło. Przy tym rodzaju MFA, użytkownik nie wpisuje hasła. Fałszywa strona nie ma niczego, co mogłaby odtworzyć.

2

Ataki adversary-in-the-middle

Serwer pośredniczący przepuszcza prawdziwe logowanie i przejmuje sesję po MFA. Uwierzytelniacz sprawdza, która strona o nie prosi. Nie odpowie domenie, która tylko wygląda podobnie.

3

Vishing i prośba o podanie kodu

Rozmówca podaje się za dział IT i prosi o jednorazowy kod - w tej sytuacji nie ma żadnego kodu, który byłby użyteczny dla atakującego.

4

Push fatigue (zasypywanie prośbami o zatwierdzenie)

Atakujący wysyła prośby tak długo, aż ktoś kliknie „Zatwierdź”. Ten rodzaj MFA nie opiera się na zatwierdzeniach w ciemno.

5

Skradzione i powtarzane hasła

Samo hasło z wycieku w innym serwisie nie wystarcza już do uzyskania dostępu do konta, nawet gdy atakujący wyłudził też hasło.

Przed i po wdrożeniu funkcjonalności

Przed
Po
PrzedWyłudzone hasło otwiera konto.
PoSamo wyłudzone hasło nie wystarczy. Atakujący potrzebuje jeszcze urządzenia lub klucza użytkownika.12
PrzedJednorazowy kod można podyktować przez telefon albo przekazać przez serwer pośredniczący.
PoNie ma kodu do podyktowania ani przekazania.
PrzedFałszywa strona wygląda tak samo, jak oryginał. Użytkownik nie widzi różnicy.
PoUwierzytelniacz odpowiada tylko prawdziwej stronie.12
PrzedKażde logowanie zależy od tego, czy użytkownik dostrzeże podstęp atakującego.
PoTo urządzenie weryfikuje - użytkownik nie musi niczego zauważać.

Jak to robią Okta i Auth0

Okta daje dwa sposoby na MFA odporne na phishing. Można je łączyć.

1

Użytkownik otwiera logowanie

Użytkownik loguje się do aplikacji chronionej przez Okta.

2

Uwierzytelniacz sprawdza stronę

Okta Verify (FastPass) lub klucz FIDO2 potwierdza, że żądanie pochodzi z prawdziwej domeny Okta.12

3

Urządzenie potwierdza obecność użytkownika

Klucz na urządzeniu podpisuje żądanie. Użytkownik potwierdza na urządzeniu, na przykład biometrią lub PIN-em.12

4

Polityka decyduje, co jest dozwolone

Okta dostarcza FIDO2 (WebAuthn) i Okta FastPass, odporne na phishing. Okta Adaptive MFA może wymagać silniejszych faktorów, gdy ryzyko logowania jest wyższe. Warto wymagać tych metod i wygaszać słabsze rodzaje faktorów MFA.35

Fałszywa strona

UżytkownikFałszywa strona✕ Wynik

Prawdziwe logowanie Okta

UżytkownikOkta✓ Wynik
WIC
Kogo chroniPracownicy, kontraktorzy, admini
Okta FastPassLogowanie bez hasła w aplikacji Okta Verify na urządzeniu użytkownika. Polityki logowania do aplikacji decydują, kiedy oferowany jest FastPass. Zaprojektowane tak, by odpierać phishing.1
FIDO2 (WebAuthn) i passkeysFIDO2 (WebAuthn) oraz passkeys można skonfigurować w Okta jako uwierzytelniacze (authenticators).28
Uwierzytelniacze odporne na phishingObecnie w Okcie można wybrać FIDO2 (WebAuthn) i Okta FastPass jako faktory MFA odporne na phishing.3
Polityki rejestracji MFATe polityki, konfigurowane w Okcie, wskazują z jakich faktorów MFA mają korzystać użytkownicy w zależności od przypisanej grupy.4
CIC
Kogo chroniUżytkownicy Twojej aplikacji
PasskeysPołączenia typu database connections w Auth0 obsługują passkeys. Klient loguje się za pomocą passkey zamiast standardowego hasła wielokrotnego użytku. Część passkeys synchronizuje się przez konto chmurowe klienta.6
Klucze WebAuthn jako faktor MFAKlucze bezpieczeństwa można skonfigurować jako jeden z faktorów MFA dostępnych dla logowań klientów.7
Adaptive MFAAuth0 Adaptive MFA wymaga silniejszych faktorów, gdy ryzyko logowania klienta jest wyższe. Jest dostępne w planach Auth0 Enterprise jako dodatek.9

Jak wdrażamy to w Zelto

Technologia za Oktą to gotowa i sprawdzona połowa - Zelto mapuje Twoje konta, urządzenia i wyjątki. Planujemy wdrożenia grupami, aby zminimalizować ryzyko i skutki. Zaczynamy od kont, na których atakującym zależy najbardziej. Dbamy też o proces odzyskiwania dostępu, którego atakujący nie obejdzie szybką rozmową z helpdeskiem.

Typowy przebieg wdrożenia

  1. Sprawdzamy, kto, jak i skąd się loguje

    Spisujemy aplikacje, uwierzytelniacze i urządzenia.

  2. Dobieramy uwierzytelniacze

    Dla maksymalnego bezpieczeństwa przed atakami typu phishing: Okta FastPass, jeżeli urządzenie może korzystać z Okta Verify. Klucze FIDO2 dla kont współdzielonych/kioskowych oraz dla kont wysokiego ryzyka. Dla klientów/konsumentów - passkeys.

  3. Pilotaż z adminami i działem IT

    Zaczynamy od najcenniejszych kont, ustalamy właścicieli odpowiednich polityk po Twojej stronie. Ustalamy też, kiedy wdrażamy zmianę i kiedy ją wycofujemy.

  4. Wdrażamy grupa po grupie

    Nie przełączamy wszystkich użytkowników jednego dnia. Każda grupa dostaje w Okcie własną politykę rejestracji MFA. Helpdesk dostaje instrukcje na pytania tej grupy. Każda grupa ma ustaloną datę przejścia.

  5. Zaostrzamy zasady i wygaszamy stare metody

    W objętych aplikacjach usuwamy słabsze faktory logowania, gdy to tylko możliwe. Wyjątki przeglądamy regularnie.

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

Klucz lub FastPass nie działa przy logowaniu.

−Pozwalamy zalogować się SMS-em, połączeniem głosowym albo powiadomieniem push. Atakujący o tym wiedzą i proszą właśnie o słabszą metodę.

+Blokujemy logowanie i kierujemy użytkownika do procesu odzyskiwania dostępu, który weryfikuje jego tożsamość.

Użytkownik traci dostęp i dzwoni do helpdesku.

−Helpdesk resetuje hasło albo dodaje nowy faktor po kilku pytaniach przez telefon.

+Helpdesk najpierw weryfikuje tożsamość dzwoniącego. Użytkownik odzyskuje dostęp tylko przez rejestrację nowego faktora odpornego na phishing.

Kontraktorzy i konta współdzielone potrzebują dostępu.

−Dajemy im te same ustawienia co pracownikom albo je pomijamy, nie sprawdzając, kto faktycznie korzysta z konta.

+Sprawdzamy, kto korzysta z każdego konta. Każdy kontraktor dostaje własne konto. Konta współdzielone i kioskowe dostają klucze FIDO2.

Zespół dzieli jeden klucz FIDO2 między kilka osób.

−Przekazujemy jeden klucz w zespole, więc nikt nie wie, kto z niego skorzystał, a zgubiony klucz dotyka wszystkich.

+Każda osoba ma własny klucz FIDO2. Do kont współdzielonych i kioskowych używamy dedykowanych kluczy, a nie osobistego klucza kopiowanego między użytkownikami.

Pracownicy logują się z prywatnych telefonów i laptopów, a telefony i klucze się gubią lub wymienia.

−Każdy rejestruje klucz na dowolnym urządzeniu, bez zapasowego klucza i bez planu na zgubiony telefon. Zablokowany użytkownik wraca do hasła lub SMS-a.

+Ustalamy, na jakich urządzeniach można trzymać klucz. Każdy użytkownik ma zapasowy klucz lub drugie urządzenie. Przed startem wdrożenia ustalamy, jak wymieniamy zgubione lub nowe urządzenie.

Chcesz logowania odpornego na phishing i wdrożenia, które nie utknie w połowie?

Sprawdzimy, jak dziś logują się Twoi pracownicy i klienci. Potem powiemy, od czego zacząć.

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

Powiązane wpisy na blogu

Praktyczne notatki z wdrożeń

Phishing-resistant MFA and FIDO rolloutCzytaj na blogu →Implement phishing-resistant MFA with Okta: a practical guideCzytaj na blogu →F is for FIDO2Czytaj na blogu →

Źródła

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

  1. 1Okta Verify and Okta FastPassOkta Help Center
  2. 2Configure passkeys (FIDO2 WebAuthn) authenticatorOkta Help Center
  3. 3Phishing-resistant authenticationOkta Help Center
  4. 4About MFA enrollment policiesOkta Help Center
  5. 5Okta Adaptive MFAokta.com product page
  6. 6Passkeys in Auth0 database connectionsAuth0 Docs
  7. 7Configure WebAuthn security keys as an MFA factorAuth0 Docs
  8. 8Okta developer guide: FIDO2 WebAuthn authenticatordeveloper.okta.com
  9. 9Adaptive MFAAuth0 Docs