MFA odporne na phishing: dlaczego nie każdy drugi składnik jest równy

Uwierzytelnianie wieloskładnikowe to nie jedno i to samo. Odległość między jednorazowym kodem wysłanym SMS-em a passkeyem opartym na sprzęcie to różnica między spowolnieniem napastnika a zatrzymaniem go całkowicie. To rozróżnienie między MFA podatnym na phishing a odpornym na phishing.

Dlaczego większość MFA wciąż jest podatna na phishing

Problem z kodami i monitami push polega na tym, że drugi składnik to wspólny sekret, który człowiek może przekazać. Jeśli użytkownik potrafi odczytać kod i wpisać go na stronie, można go nakłonić do wpisania go na stronie napastnika.

• Kody SMS / TOTP — proxy napastnika w środku (AiTM), takie jak Evilginx, prezentuje idealny klon logowania, przekazuje dane logowania i kod OTP w czasie rzeczywistym oraz przechwytuje powstały plik cookie sesji. Ważny kod nic nie daje.
• Powiadomienia push — podatne na zmęczenie MFA / bombardowanie monitami: powtarzane zatwierdzenia, aż zmęczony użytkownik dotknie „Zatwierdź”.
• Podmiana karty SIM (SIM swapping) — przenosi numer ofiary na kartę SIM napastnika, pokonując SMS w całości.

Dopasowanie numerów i kontekst geograficzny w push pomagają, ale są łagodzeniem na fundamentalnie podatnym projekcie.

Co czyni MFA odpornym na phishing

MFA odporne na phishing usuwa człowieka z decyzji o zaufaniu. Liczą się dwie właściwości:

• Wiązanie z pochodzeniem — dane logowania są kryptograficznie związane z dokładnym pochodzeniem WWW, dla którego je zarejestrowano. Podobna domena albo proxy po prostu się nie zgadza, więc uwierzytelnienie po cichu zawodzi.
• Brak wspólnego sekretu w tranzycie — uwierzytelnianie używa wyzwanie-odpowiedź z kluczem prywatnym, który nigdy nie opuszcza urządzenia.

Standardy, które to zapewniają:

• FIDO2 / WebAuthn — standard przeglądarki i platformy dla uwierzytelniania kluczem publicznym.
• Passkeye — dane logowania FIDO2, albo związane z urządzeniem (sprzętowy klucz bezpieczeństwa, np. YubiKey), albo synchronizowane (kopiowane w ekosystemie dostawcy, jak Apple, Google albo menedżer haseł).
• PIV / karty inteligentne (x.509) — od dawna stosowane podejście korporacyjne i rządowe.

Dlaczego proxy AiTM przegrywają z tym

Użytkownik → phish.example (proxy napastnika) → real.example

Asercja WebAuthn jest podpisywana nad pochodzeniem, które widzi przeglądarka:
  clientDataJSON.origin = "https://phish.example"
Dane logowania zarejestrowano dla "https://real.example"
→ niezgodność pochodzenia → authenticator/RP odrzuca asercję

Nie ma kodu, który użytkownik mógłby przekazać, ani pliku cookie, który proxy mogłoby zebrać, bo logowanie nigdy nie powiedzie się wobec złego pochodzenia. Wymusza to przeglądarka — nie człowiek.

Wdrażanie bez psucia rzeczy

Priorytetyzuj według ryzyka. Zacznij od administratorów, finansów, kadry kierowniczej i każdego z dostępem do systemów o kluczowym znaczeniu. To konta, które zestawy AiTM biorą na cel najpierw.

Zaplanuj odzyskiwanie konta. Odzyskiwanie to nowy czuły punkt — jeśli zgubiony klucz wraca do SMS albo telefonu na help desk, ponownie wprowadziłeś ścieżkę podatną na phishing. Wymagaj dwóch zarejestrowanych authenticatorów na użytkownika (np. klucz bezpieczeństwa plus passkey platformowy) i wzmocnij weryfikację tożsamości na help desku.

Zarządzaj mieszanym parkiem. Synchronizowane passkeye ułatwiają wdrożenie na urządzeniach osobistych i mobilnych; klucze związane z urządzeniem pasują do scenariuszy wysokiej pewności oraz współdzielonych/kiosk. Wiele organizacji stosuje oba.

Rozłóż migrację w czasie:

1. Włącz FIDO2/passkeye obok istniejącego MFA.
2. Zarejestruj drugi składnik i prowadź kampanie rejestracji.
3. Przenieś role uprzywilejowane na wymagane odporne na phishing.
4. Usuń SMS i głos jako składniki.
5. Rozszerz wymóg odporności na phishing na całą organizację przez dostęp warunkowy.

Dąż do tego, by odporność na phishing była wymagana, a nie tylko dostępna. Dopóki istnieje podatny na phishing wariant zapasowy, napastnicy będą kierować użytkowników do niego — technika znana jako degradacja MFA.

Jak pomaga GottaPhish

Podatne na phishing MFA — OTP i push — daje fałszywe poczucie bezpieczeństwa, pozostawiając realną lukę, którą napastnicy aktywnie wykorzystują; samo posiadanie technologii jej nie zamyka. GottaPhish i jego zespół ekspertów pomagają zbudować uzasadnienie biznesowe i przeprowadzić wdrożenie: nasze symulacje w stylu AiTM pokazują bezpiecznie i mierzalnie, jak MFA oparte na OTP i push pada wobec prawdziwego proxy, dając kierownictwu dowód na sfinansowanie MFA odpornego na phishing. Stamtąd nasi eksperci prowadzą Twoje wdrożenie FIDO2/passkeyów bezpośrednio — priorytetyzując role wysokiego ryzyka, planując rejestrację dwóch authenticatorów i odzyskiwanie oraz raportując adopcję obok metryk kliknięć i zgłoszeń — i pomagają interpretować wyniki, abyś mógł udowodnić, że podatna luka rzeczywiście się zamyka.