MFA ist nicht gleich MFA: Warum ein zweiter Faktor Phishing nicht automatisch stoppt

Ein Login verlangt Passwort plus sechsstelligen Code. Ein anderer wird mit einem Passkey bestätigt. In vielen Sicherheitslisten steht bei beiden derselbe Haken: MFA aktiviert.

Technisch ist das zu grob. Zwei Faktoren sagen zunächst, wie viele voneinander verschiedene Nachweise eine Anmeldung verlangt. Sie sagen noch nicht, ob sich diese Nachweise an eine gefälschte Login-Seite weiterreichen lassen. Genau dort liegt der Unterschied zwischen klassischer MFA und phishing-resistenter Authentisierung.

Die aktuellen Digital Identity Guidelines des NIST machen diese Trennung ungewöhnlich klar. Auf Authentication Assurance Level 2 sind mehrere MFA-Varianten möglich. Gleichzeitig muss ein Verifier mindestens eine phishing-resistente Option anbieten. Faktorzahl und Phishing-Resistenz sind also zwei verschiedene Eigenschaften desselben Login-Prozesses.

Zwei Faktoren sind eine Kategorie, kein Sicherheitsniveau

Bei MFA werden unterschiedliche Faktoren kombiniert: etwas, das ein Nutzer weiß, besitzt oder ist. Ein Passwort plus Einmalcode erfüllt dieses Grundprinzip. Dasselbe gilt für bestimmte kryptografische Authenticatoren, die zusätzlich per PIN oder Biometrie aktiviert werden.

Für die Sicherheitsbewertung reicht die Zählung aber nicht. NIST unterscheidet zusätzlich unter anderem Replay-Resistenz, Phishing-Resistenz, Authentication Intent und die Frage, ob ein kryptografischer Schlüssel exportierbar ist. Ein Login kann auf einer Achse stark und auf einer anderen schwächer sein.

Das erklärt eine scheinbare Merkwürdigkeit in den NIST-Beispielen: Ein einmalig verwendbarer OTP kann gegen schlichtes Wiederverwenden eines alten Codes geschützt sein und trotzdem nicht als phishing-resistent gelten. Umgekehrt kann ein kryptografischer Passkey ohne zusätzliche lokale Nutzerverifikation phishing-resistent sein, obwohl NIST ihn als Single-Factor-Cryptographic Authenticator einordnet.

„MFA“ beschreibt also nicht automatisch die gesamte Sicherheitsqualität eines Verfahrens.

Ein Einmalcode kann Replay verhindern und trotzdem gephisht werden

Replay-Resistenz beantwortet eine enge Frage: Kann ein Angreifer eine bereits beobachtete Authentisierungsnachricht später einfach noch einmal verwenden? Bei OTP-Verfahren verhindert der einmalige oder zeitlich begrenzte Code genau dieses simple Wiederholen.

Phishing funktioniert anders. Eine gefälschte Seite kann den Nutzer dazu bringen, einen gerade gültigen Code einzugeben. Wird dieser Code in Echtzeit an den echten Dienst weitergereicht, hilft es wenig, dass derselbe Code später nicht noch einmal funktioniert.

NIST definiert Phishing-Resistenz deshalb als Eigenschaft des Protokolls: Es soll verhindern, dass Authentisierungsgeheimnisse oder gültige Authenticator-Ausgaben an einen betrügerischen Verifier preisgegeben werden, ohne sich auf die Wachsamkeit des Nutzers verlassen zu müssen. Verfahren, bei denen ein Nutzer einen OTP oder eine andere Ausgabe manuell eingibt, erfüllen diese Bedingung ausdrücklich nicht.

Das BSI beschreibt denselben Angriffsweg anschaulich: Eine täuschend echte Website kann neben dem Passwort auch den Code aus einer Authenticator-App abfragen und beides in Echtzeit übernehmen. Der zweite Faktor ist vorhanden. Der Phishing-Kanal bleibt trotzdem offen.

Push macht MFA bequemer, aber nicht automatisch phishing-resistent

Push-Verfahren nehmen dem Nutzer das Abtippen eines Codes ab. Das löst jedoch nicht automatisch die Bindung an den legitimen Dienst. Zusätzlich entsteht ein anderes Problem: Wer wiederholt Freigabeanfragen auf ein Smartphone schickt, kann darauf hoffen, dass eine davon irgendwann bestätigt wird.

CISA behandelt deshalb einfaches Push-MFA nicht als Zielzustand. Number Matching – also eine zusätzliche Zahl, die zwischen Login-Sitzung und App abgeglichen wird – ist eine stärkere Zwischenstufe gegen Push-Bombing. Die Behörde empfiehlt sie ausdrücklich für Organisationen, die phishing-resistente MFA noch nicht sofort einführen können.

Das Wort „Zwischenstufe“ ist wichtig. Number Matching reduziert einen konkreten Angriffsweg. Es macht ein Verfahren nicht automatisch zu WebAuthn.

WebAuthn bindet die Anmeldung an den echten Dienst

Bei WebAuthn verschiebt sich die Logik. Statt eines Codes, den der Nutzer auf irgendeiner Seite eingeben kann, arbeitet der Authenticator mit einem kryptografischen Schlüsselpaar. Die öffentliche Seite kennt der Dienst; der private Schlüssel bleibt beim Authenticator.

Entscheidend ist die Bindung an die Relying Party. Die aktuelle WebAuthn-Level-3-Spezifikation des W3C beschreibt Public-Key-Credentials, die auf eine bestimmte Relying Party begrenzt sind. NIST nennt WebAuthn deshalb als Beispiel für „Verifier Name Binding“: Der Authenticator erzeugt seine Antwort für den authentifizierten Domain-Kontext des legitimen Dienstes.

Eine gefälschte Seite kann den Nutzer weiterhin täuschen. Sie bekommt aber nicht einfach einen universell weiterverwendbaren Einmalcode, den sie beim echten Dienst einreichen kann. Genau darin liegt die architektonische Phishing-Resistenz.

Passkey bedeutet nicht automatisch höchste Assurance

„Passkey“ wird inzwischen oft wie ein einzelnes Sicherheitsniveau behandelt. Auch das ist zu grob.

Die aktuellen NIST-Ressourcen unterscheiden beispielsweise zwischen Passkeys ohne User Verification und FIDO2-Passkeys mit User Verification. Ersteres kann als Single-Factor-Cryptographic Authenticator eingeordnet werden, letzteres als Multi-Factor-Cryptographic Authenticator. Beide können phishing-resistent sein, obwohl die Faktorlogik verschieden ist.

Auch die Speicherung des Schlüssels spielt eine Rolle. Synchronisierbare Authenticatoren können laut NIST bis AAL2 eingesetzt werden, wenn die zusätzlichen Anforderungen erfüllt sind. Für AAL3 verlangt NIST dagegen einen nicht exportierbaren privaten Schlüssel. Ein synchronisierter Passkey verletzt genau diese Non-Exportability-Anforderung.

Das ist kein Argument gegen synchronisierte Passkeys. Es zeigt nur, warum „phishing-resistent“, „MFA“ und „höchstes Assurance-Level“ nicht als Synonyme behandelt werden sollten.

Die Gegenposition: Schwächere MFA ist deshalb nicht nutzlos

Aus der technischen Hierarchie lässt sich leicht die falsche Konsequenz ziehen: Wenn OTP oder SMS nicht phishing-resistent sind, kann man sie gleich abschaffen.

CISA argumentiert ausdrücklich anders. Jede MFA ist grundsätzlich besser als gar keine MFA. SMS, OTP oder Push können viele Angriffe auf reine Passwortkonten deutlich erschweren. Die Behörde empfiehlt aber zugleich, stärkere Verfahren zu priorisieren und den Übergang zu phishing-resistenter Authentisierung zu planen.

Das ist für reale Unternehmen die wichtigere Perspektive. Legacy-Anwendungen unterstützen nicht immer sofort WebAuthn. Manche Nutzergruppen brauchen Übergangslösungen. Ein harter Cut kann dazu führen, dass Teams Ausnahmen bauen oder Zugänge wieder auf schwächere Muster zurückfallen.

Eine Migrationsstrategie darf deshalb Zwischenstufen kennen. Sie sollte nur nicht aus einer Zwischenstufe ein Endziel machen.

MFA-Auswahl sollte mit dem Angriff beginnen, nicht mit dem Produktnamen

Für die Praxis reichen vier Prüfbereiche. Sie ergeben sich direkt aus den Eigenschaften, die NIST, CISA und WebAuthn voneinander trennen.

Für besonders kritische Konten spricht viel dafür, Phishing-Resistenz früh zu priorisieren. CISA empfiehlt Unternehmen ebenfalls, mit Administratoren und Beschäftigten mit sensiblen Daten zu beginnen. Wo das technisch noch nicht möglich ist, sind stärkere App-Verfahren und Number Matching sinnvoller als der Rückfall auf Passwort-only.

Und Schulung bleibt relevant. Phishing-resistente Authentisierung reduziert die Abhängigkeit davon, dass ein Mensch eine gefälschte Login-Seite rechtzeitig erkennt. Sie beseitigt aber weder betrügerische Mails noch andere Social-Engineering- oder Malware-Risiken. Wie belastbar Phishing-Simulationen und ihre Klickrate als Awareness-Maß sind, ist deshalb eine separate Frage.

Der zweite Faktor ist nur der Anfang der Sicherheitsfrage

MFA bleibt eine wichtige Sicherheitskontrolle. Aber „MFA aktiv“ ist für Architektur, Beschaffung oder Audit zu wenig Information.

Ein OTP kann einmalig und replay-resistent sein, ohne phishing-resistent zu sein. Ein WebAuthn-Credential kann phishing-resistent sein, obwohl nicht jede Variante dasselbe Faktor- oder Assurance-Niveau erreicht. Push und Number Matching können sinnvolle Übergangsstufen sein, ohne das Zielbild zu ersetzen.

Die bessere Prüffrage lautet deshalb: Welcher Authenticator schützt welchen Zugang gegen welchen Angriff – und welche Restschwäche akzeptieren wir bewusst?

Damit wird aus dem MFA-Häkchen eine echte Sicherheitsentscheidung.