Phishing-resistente MFA: warum nicht jede Zwei-Faktor-Methode gleich ist

Mehr-Faktor-Authentifizierung ist nicht eine einzige Sache. Der Abstand zwischen einem per SMS geschickten Einmalcode und einem hardwaregestützten Passkey ist der Unterschied zwischen einen Angreifer bremsen und ihn ganz stoppen. Das ist die Unterscheidung zwischen phishbarer und phishing-resistenter MFA.

Warum die meiste MFA weiter phishbar ist

Das Problem an Codes und Push-Aufforderungen: Der zweite Faktor ist ein geteiltes Geheimnis, das der Mensch weitergeben kann. Wenn eine Nutzerin einen Code lesen und in eine Seite tippen kann, kann sie dazu verleitet werden, ihn in die Seite eines Angreifers zu tippen.

• SMS-/TOTP-Codes — ein Angreifer-in-der-Mitte-Proxy (AiTM) wie Evilginx zeigt einen pixelgenauen Login-Klon, leitet die Zugangsdaten und das OTP in Echtzeit weiter und fängt das entstehende Session-Cookie ab. Der gültige Code bringt nichts.
• Push-Benachrichtigungen — anfällig für MFA-Ermüdung / Prompt-Bombing: wiederholte Freigaben, bis eine müde Person auf „Genehmigen“ tippt.
• SIM-Swapping — verschiebt die Nummer des Opfers auf die SIM eines Angreifers und hebelt SMS vollständig aus.

Nummernabgleich und Geo-Kontext beim Push helfen, aber sie sind Abmilderungen an einem grundsätzlich phishbaren Design.

Was MFA phishing-resistent macht

Phishing-resistente MFA nimmt den Menschen aus der Vertrauensentscheidung. Zwei Eigenschaften zählen:

• Ursprungsbindung — die Zugangsdaten sind kryptografisch an genau den Web-Ursprung gebunden, für den sie registriert wurden. Eine ähnlich aussehende oder Proxy-Domain passt schlicht nicht, sodass die Anmeldung stillschweigend scheitert.
• Kein geteiltes Geheimnis in Übertragung — die Anmeldung nutzt ein Challenge-Response mit einem privaten Schlüssel, der das Gerät nie verlässt.

Die Standards, die das liefern:

• FIDO2 / WebAuthn — der Browser- und Plattformstandard für Public-Key-Authentifizierung.
• Passkeys — FIDO2-Zugangsdaten, entweder gerätegebunden (Hardware-Sicherheitsschlüssel, etwa YubiKey) oder synchronisiert (über ein Anbieter-Ökosystem wie Apple, Google oder einen Passwortmanager gesichert).
• PIV / Smartcards (x.509) — der althergebrachte Ansatz in Unternehmen und Behörden.

Warum AiTM-Proxys daran scheitern

Nutzer → phish.example (Angreifer-Proxy) → real.example

Die WebAuthn-Assertion wird über den Ursprung signiert, den der Browser sieht:
  clientDataJSON.origin = "https://phish.example"
Die Zugangsdaten wurden für "https://real.example" registriert
→ Ursprungs-Mismatch → der Authenticator/RP weist die Assertion ab

Es gibt keinen Code, den die Nutzerin weiterreichen könnte, und kein Cookie, das der Proxy abgreifen könnte, weil die Anmeldung gegen den falschen Ursprung nie gelingt. Der Browser erzwingt das — nicht der Mensch.

Einführen, ohne etwas zu zerbrechen

Nach Risiko priorisieren. Beginnen Sie mit Admins, Finanzen, Führung und allen mit Zugriff auf Kronjuwelen-Systeme. Das sind die Konten, die AiTM-Kits zuerst ins Visier nehmen.

Kontowiederherstellung einplanen. Die Wiederherstellung ist die neue weiche Flanke — fällt ein verlorener Schlüssel auf SMS oder einen Helpdesk-Anruf zurück, haben Sie den phishbaren Weg wieder eingeführt. Verlangen Sie zwei registrierte Authenticatoren je Person (etwa einen Sicherheitsschlüssel plus einen Plattform-Passkey) und härten Sie die Identitätsprüfung am Helpdesk.

Gemischte Bestände handhaben. Synchronisierte Passkeys erleichtern den Rollout auf privaten und mobilen Geräten; gerätegebundene Schlüssel passen für hohe Sicherheitsanforderungen und geteilte/Kiosk-Szenarien. Viele Organisationen fahren beides.

Die Migration takten:

1. FIDO2/Passkeys neben der bestehenden MFA aktivieren.
2. Einen zweiten Faktor registrieren und Enrollment-Kampagnen antreiben.
3. Privilegierte Rollen auf phishing-resistent erforderlich stellen.
4. SMS und Sprache als Faktoren entfernen.
5. Die Phishing-Resistenz-Anforderung per Conditional Access organisationsweit ausweiten.

Zielen Sie auf phishing-resistent als erforderlich, nicht bloß verfügbar. Solange ein phishbarer Rückfallweg existiert, lenken Angreifer die Nutzer dorthin — eine Technik namens MFA-Downgrade.

Wie GottaPhish hilft

Phishbare MFA — OTP und Push — vermittelt ein trügerisches Sicherheitsgefühl und lässt zugleich eine echte Lücke, die Angreifer aktiv ausnutzen; die Technik zu besitzen schließt sie nicht. GottaPhish und sein Expertenteam helfen Ihnen, den Business Case zu bauen und den Rollout umzusetzen: Unsere AiTM-artigen Simulationen zeigen sicher und messbar, wie OTP- und Push-MFA vor einem echten Proxy fallen, und geben der Führung den Beleg, um phishing-resistente MFA zu finanzieren. Von dort begleiten unsere Fachleute Ihre FIDO2/Passkey-Einführung direkt — priorisieren Rollen mit hohem Risiko, planen die Zwei-Authenticator-Registrierung und die Wiederherstellung und berichten über die Adoption neben Ihren Klick- und Meldekennzahlen — und helfen beim Deuten der Ergebnisse, damit Sie belegen können, dass die phishbare Lücke sich tatsächlich schließt.