Phishing-resistente Authentifizierung: Was macht sie tatsächlich widerstandsfähig?

Phishing-resistente Authentifizierung wird häufig als „starke MFA“ beschrieben. Der entscheidende Unterschied ist jedoch nicht einfach die Anzahl der Faktoren. Entscheidend ist, ob ein Angreifer einen Benutzer dazu bringen kann, eine Authentifizierung zu bestätigen, die der Angreifer anschließend an anderer Stelle wiederverwenden kann.

Modernes Phishing funktioniert häufig in Echtzeit. Eine gefälschte Website kann Zugangsdaten an den echten Dienst weiterleiten, Einmalcodes abfangen und Freigabeaufforderungen unmittelbar weiterreichen. Eine Authentifizierung wird dann wirklich phishing-resistent, wenn der Nachweis kryptografisch an den legitimen Dienst oder Origin gebunden ist, statt aus einem wiederverwendbaren Geheimnis zu bestehen, das kopiert oder weitergeleitet werden kann.

Dieser Leitfaden erklärt die wichtigsten Eigenschaften hinter dieser Widerstandsfähigkeit und zeigt, wie ZTXBAS sie umsetzt.

1. Warum Passwörter und Einmalcodes leicht weitergeleitet werden können​

Passwörter, SMS-Codes und TOTP-Werte sind Informationen, die ein Benutzer an der falschen Stelle eingeben kann.

Ein Phishing-Proxy kann:

1. eine überzeugende Kopie der echten Anmeldeseite anzeigen
2. Benutzername und Passwort erfassen
3. diese an den legitimen Dienst weiterleiten
4. den Benutzer nach dem SMS- oder TOTP-Code fragen, den der echte Dienst erzeugt hat
5. den Code weiterleiten, bevor er abläuft

Der Code kann weiterhin gültig sein, obwohl der Benutzer ihn auf der falschen Website eingegeben hat, weil der Code selbst nicht an die Website gebunden ist, die ihn angefordert hat.

Push-Freigaben verbessern die Bedienbarkeit, können aber eine ähnliche Schwäche haben, wenn der Benutzer nur eine allgemeine Aufforderung wie „Anmeldung genehmigen?“ sieht. Ist die Freigabe nicht an den vorgesehenen Dienst gebunden, kann ein Benutzer eine Anfrage genehmigen, die über eine Phishing-Sitzung ausgelöst wurde.

2. Biometrie allein erzeugt keine Phishing-Resistenz​

Ein Fingerabdruck oder Gesichtsscan beweist, dass ein lokaler Benutzer die biometrische Verifizierung auf einem Gerät bestanden hat. Allein daraus ergibt sich jedoch nicht, wofür der Benutzer sich authentifizieren wollte.

Die wichtigen Fragen beginnen nach der biometrischen Prüfung:

• Für welche Anwendung oder welchen Origin gilt die Freigabe?
• Ist dieses Ziel für den Benutzer sichtbar?
• Ist der resultierende Nachweis an dieses Ziel gebunden?
• Kann der Nachweis bei einer anderen Anwendung wiederverwendet werden?
• Verlässt der private Schlüssel jemals das Gerät?

Phishing-Resistenz entsteht durch das Protokoll rund um die biometrische Prüfung, nicht allein durch den biometrischen Sensor.

3. Origin Binding bindet die Freigabe an die vorgesehene Anwendung​

Origin Binding ist der zentrale Kontrollmechanismus in ZTXBAS.

Wenn eine Anwendung eine Authentifizierungs-Challenge erzeugt, gibt sie den erwarteten Origin an. ZTXBAS akzeptiert die Anfrage nur, wenn dieser Origin für die Anwendung registriert ist. Der kanonische Origin wird anschließend durch die Challenge mitgeführt und dem Benutzer vor der Freigabe auf dem Mobilgerät angezeigt.

Eine Freigabe für:

https://app.example.com

kann beispielsweise nicht einfach für Folgendes umfunktioniert werden:

https://phishing.example.com

Der Phishing-Origin ist nicht für die legitime Anwendung registriert, und der authentifizierte Nachweis enthält den Origin, für den er tatsächlich ausgestellt wurde.

Damit können beide Seiten etwas Konkretes prüfen:

• der Benutzer sieht das Ziel, das er freigibt
• die vertrauende Anwendung erhält einen Nachweis mit demselben Origin

Das Backend sollte den Origin-Claim nach der Signaturprüfung weiterhin explizit validieren. Phishing-Resistenz hängt davon ab, die Bindung durchzusetzen, nicht nur das Feld mitzuführen.

Technische Dokumentation zum Origin Binding

4. Gerätegebundene Schlüssel halten die private Anmeldeinformation auf dem Gerät​

ZTXBAS verwendet gerätegebundene kryptografische Schlüssel. Private Schlüssel verbleiben, soweit verfügbar, im Secure Enclave oder in einer Trusted Execution Environment des Geräts; biometrische Vorlagen verlassen das Gerät nicht.

Dadurch verändert sich das Angriffsziel.

Es gibt kein gemeinsames biometrisches Geheimnis, das eine Phishing-Seite sammeln und wiederverwenden könnte. Der Server erhält einen kryptografischen Nachweis, den das registrierte Gerät erzeugt hat, statt eines wiederverwendbaren, passwortähnlichen Werts, der aus der Biometrie abgeleitet wird.

Die Biometrie autorisiert also die Nutzung eines auf dem Gerät gespeicherten Schlüssels; die biometrischen Daten selbst werden nicht an die vertrauende Anwendung übertragen.

5. Kurzlebige signierte Nachweise reduzieren den Wert abgefangener Beweise​

Nach einer erfolgreichen Challenge stellt ZTXBAS einen kurzlebigen ES256-JWT-Identitätsnachweis aus.

Der Nachweis enthält unter anderem:

• authentifizierten Benutzer
• Aussteller
• Audience und Origin
• Ausstellungs- und Ablaufzeit
• Challenge-ID

Die vertrauende Anwendung verifiziert den JWT mit dem öffentlichen JWKS des ZTXBAS-Servers. Vor dem Aufbau einer eigenen Anwendungssitzung sollte sie Signatur, erwarteten Algorithmus, Ablaufzeit, gegebenenfalls den Aussteller und den erwarteten Origin prüfen.

Da der Nachweis signiert und kurzlebig ist, entspricht er keinem dauerhaften Bearer-Credential. Anwendungen mit höheren Anforderungen an Replay-Schutz können zusätzlich kürzlich verwendete Challenge-IDs nachhalten und Wiederverwendung ablehnen.

Leitfaden zur JWT-Verifizierung

6. Auch die vertrauende Anwendung muss sich gegenüber dem Authentifizierungsdienst ausweisen​

Phishing-Resistenz betrifft nicht nur die Benutzerseite.

Bei ZTXBAS signieren Anwendungen ihre API-Anfragen mit HMAC-SHA256. Bevor eine Challenge erzeugt wird, prüft der Server, ob die Anfrage von der registrierten Anwendung stammt, ob der angeforderte Origin zu dieser Anwendung gehört und ob der Benutzer existiert.

Dadurch kann eine beliebige Phishing-Seite den legitimen ZTXBAS-Server nicht einfach dazu veranlassen, unter der Identität einer anderen Anwendung eine gültige Challenge für sich selbst zu erzeugen.

Das Anwendungsgeheimnis bleibt deshalb ein serverseitiges Credential und darf niemals in Browsercode oder einer mobilen Client-Anwendung offengelegt werden.

HMAC-Anfragesignierung verstehen

7. Der Benutzer braucht weiterhin hilfreichen Kontext​

Kryptografie kann eine Anfrage an einen Origin binden, aber die Benutzererfahrung bleibt wichtig.

Ein guter Freigabeablauf sollte genügend Kontext anzeigen, damit der Benutzer erkennt, was er bestätigt. ZTXBAS zeigt den registrierten Origin vor der Freigabe auf dem Mobilgerät an.

Damit lässt sich eine echte Anfrage besser von einer unerwarteten unterscheiden. Gleichzeitig vermeidet man unspezifische Freigabeaufforderungen ohne Zielinformation.

Organisationen sollten Benutzer weiterhin anweisen, unerwartete Authentifizierungsanfragen abzulehnen. Phishing-Resistenz erschwert die Wiederverwendung einer Freigabe; sie macht verdächtige Anfragen nicht harmlos.

8. Phishing-Resistenz ersetzt nicht die übrige Zugriffskontrolle​

Ein phishing-resistentes Authentifizierungsereignis liefert einen konkreten Identitätsnachweis. Es beantwortet nicht jede Autorisierungsfrage.

Anwendungen müssen möglicherweise weiterhin entscheiden:

• ob der Benutzer überhaupt ein Konto haben soll
• welche Rolle der Benutzer besitzt
• auf welche Ressource er zugreifen darf
• ob das Gerät vertrauenswürdig ist
• ob eine zusätzliche Genehmigung erforderlich ist
• wie lange die entstehende Sitzung gültig sein soll

Standalone-ZTXBAS stellt einer Anwendung den Authentifizierungsnachweis bereit. Die Anwendung bleibt für ihre eigene Sitzung und ihr Autorisierungsmodell verantwortlich.

Wird ZTXBAS zusammen mit ZTXGate lizenziert, ist die biometrische Funktion in ZTXGate integriert und kann als Teil einer breiteren Zugriffsrichtlinie genutzt werden, ohne einen separaten ZTXBAS-Server zu erfordern.

9. Beziehung zu Passkeys und WebAuthn​

Auch Passkeys und WebAuthn sind phishing-resistent ausgelegt, weil ihre kryptografischen Credentials an die legitime Relying Party gebunden sind und nicht in beliebige Websites eingegeben werden.

ZTXBAS verwendet ein anderes Interaktionsmodell: Ein serververmittelter biometrischer Push erzeugt einen signierten JWT, den die vertrauende Anwendung serverseitig prüft.

Die Ansätze können sich ergänzen. Eine Browseranwendung kann Passkeys für die primäre Anmeldung und ZTXBAS für Step-up-Authentifizierung, mobile Abläufe oder andere Nicht-Browser-Interaktionen verwenden, die vom gleichen signierten Nachweismodell profitieren.

ZTXBAS ist nicht FIDO-zertifiziert.

10. Auch das Bereitstellungsmodell ist relevant​

Die Verfügbarkeit der Authentifizierung kann Teil der Sicherheitsarchitektur werden, wenn geschützte Systeme ohne öffentliche Cloud-Abhängigkeit funktionieren müssen.

Standalone-ZTXBAS ist selbst gehostet und benötigt weder ein CoreZT-Konto noch Telemetrie- oder Lizenzserver. Es kann auch in einem Air-Gapped-Netz betrieben werden, sofern benötigte lokale Dienste – etwa ein interner SMTP-Relay für Enrollment-E-Mails – lokal verfügbar sind.

Die in ZTXGate integrierte ZTXBAS-Funktion kann ebenfalls in vollständig isolierten ZTXGate-Deployments ohne separaten ZTXBAS-Server arbeiten.

Das macht nicht ein Bereitstellungsmodell grundsätzlich besser als ein anderes. Es ist jedoch eine wichtige Designfrage: Welche externen Dienste müssen erreichbar bleiben, damit Authentifizierung weiter funktioniert?

11. Praktische Evaluierungs-Checkliste​

Wenn Sie ein Authentifizierungssystem bewerten, das als phishing-resistent bezeichnet wird, fragen Sie:

• Ist der Authentifizierungsnachweis kryptografisch an die vorgesehene Relying Party oder den Origin gebunden?
• Kann ein Benutzer den primären Nachweis in eine vom Angreifer kontrollierte Seite eingeben oder kopieren?
• Ist das Ziel vor der Freigabe für den Benutzer sichtbar?
• Sind private Schlüssel gerätegebunden und werden sie, soweit verfügbar, durch Plattformhardware geschützt?
• Erhält der Server biometrische Daten oder nur den Nachweis einer erfolgreichen lokalen biometrischen Prüfung?
• Sind Assertions kurzlebig und signiert?
• Prüft die vertrauende Anwendung Aussteller, Ablaufzeit, Audience/Origin und Algorithmus statt nur die Signatur?
• Kann ein Angreifer ohne das serverseitige Credential der Anwendung gültige Challenges erzeugen?
• Wie werden verlorene Geräte widerrufen und neu registriert?
• Welche Netzwerk- oder Cloud-Abhängigkeiten müssen während der Authentifizierung erreichbar sein?

Ein Produkt sollte diese Fragen auf Protokoll- und Betriebsebene beantworten können, nicht nur mit einem MFA-Label.

Wie ZTXBAS diese Eigenschaften umsetzt​

ZTXBAS kombiniert:

• Validierung registrierter Origins
• Anzeige des Origins vor der Freigabe
• durch die mobile Plattform geschützte gerätegebundene Schlüssel
• biometrische Benutzerverifizierung auf dem Gerät
• HMAC-authentifizierte Anwendungsanfragen
• kurzlebige ES256-Identitätsnachweise
• serverseitige Verifizierung über JWKS

Dadurch kann die vertrauende Anwendung nicht nur prüfen, wer die Challenge bestätigt hat, sondern auch, für welchen Origin diese Freigabe ausgestellt wurde.

Für Implementierungsdetails können Sie direkt in die technische Dokumentation wechseln oder den eigenständigen Server evaluieren.

Verwandte Authentifizierungsressourcen​

• ZTXBAS-Dokumentation — Implementierung, API, SDKs und Hardening.
• ZTXBAS — Produktüberblick und Bereitstellungsmodell.
• Identität und Gerätevertrauen — sehen Sie, wie Authentifizierung in umfassendere ZTXGate-Richtlinien eingebunden wird.