Die meisten Vergleiche dieser beiden Optionen laufen auf Bequemlichkeit gegen Sicherheit hinaus, mit der vagen Behauptung, Schlüssel seien "sicherer". Es gibt eine präzisere Antwort, und sie steht in einem Standard geschrieben.
Der Satz, der die Phishing-Frage klärt
NIST SP 800-63B, Abschnitt 5.2.5, ist darin unmissverständlich. Authentifikatoren, die die manuelle Eingabe einer Authentifikator-Ausgabe erfordern, etwa Out-of-Band- und OTP-Authentifikatoren, dürfen nicht als verifier-impersonation-resistant gelten, weil die manuelle Eingabe die Authentifikator-Ausgabe nicht an die konkret authentifizierte Sitzung bindet.
Derselbe Abschnitt erklärt den Angriff, statt ihn implizit zu lassen: bei einem Machine-in-the-Middle-Angriff könnte ein gefälschter Verifier die OTP-Authentifikator-Ausgabe an den echten Verifier weiterspielen und sich erfolgreich authentifizieren.
Das ist der ganze Mechanismus. Dein sechsstelliger Code ist korrekt. Er ist nur eben überall korrekt, auch auf einer Seite, die bloß aussieht wie deine Bank.
Warum die Bindung der eigentliche Unterschied ist
Der Standard definiert Verifier-Impersonation-Resistance so: einen authentifizierten geschützten Kanal mit dem Verifier aufbauen und dann eine Kanalkennung stark und unumkehrbar an die Authentifikator-Ausgabe binden, zum Beispiel indem beide Werte gemeinsam mit einem privaten Schlüssel signiert werden.
Lies das gegen das, was jede Methode physisch tut.
Eine Authenticator-App erzeugt eine Zahl aus einem gemeinsamen Geheimnis und einer Uhr. Sie erfährt nie, auf welcher Seite du bist. Du bist die Transportschicht, und du kannst fehlgeleitet werden.
Ein Sicherheitsschlüssel signiert eine Challenge zusammen mit der Identität der Sitzung. Die FIDO Alliance beschreibt passkeys so, dass sie gängige Public-Key-Kryptografie nutzen, um phishing-resistente Authentifizierung zu ermöglichen. Es gibt keine Zahl, die du vorlesen müsstest, und daher nichts, was ein Angreifer weiterreichen kann.
Wie der Angriff aus deiner Sicht aussieht
Die Abstraktion verdeckt, wie gewöhnlich das abläuft, deshalb lohnt es sich, es durchzugehen.
Du erhältst eine Nachricht zu deinem Konto. Der Link führt auf eine Seite, die korrekt dargestellt wird, weil der Server des Angreifers die echte Seite abruft und durchreicht. Du gibst dein Passwort ein. Der Server des Angreifers übermittelt es sofort an die echte Seite. Die echte Seite fragt nach einem zweiten Faktor, also fragt die gefälschte Seite dich ebenfalls danach.
Du öffnest deine App und liest sechs Ziffern ab. Der Server des Angreifers gibt sie innerhalb desselben Dreißig-Sekunden-Fensters auf der echten Seite ein. Die echte Seite sieht ein gültiges Passwort und einen gültigen Code und stellt eine Sitzung aus. Der Angreifer hält nun diese Sitzung.
Beachte, was nie passiert ist. Nichts wurde geknackt, kein Geheimnis wurde von deinem Telefon gestohlen, und deine App hat sich genau so verhalten, wie sie entworfen wurde. Der Code war echt. Er wurde nur an einer Stelle verwendet, die du nicht vorgesehen hattest, und weder du noch die App hattet eine Möglichkeit, das zu bemerken, denn der Code trägt keine Information über sein Ziel.
Wiederhole dieselbe Abfolge mit einem Sicherheitsschlüssel, und sie endet beim zweiten Faktor. Der Schlüssel erzeugt keine Zahl, die du weiterreichen könntest. Er signiert eine Antwort, die an die tatsächlich anfragende Seite gebunden ist, der Server des Angreifers erhält also etwas, das nur auf seiner eigenen Domain funktioniert und für ihn wertlos ist.
Wo ein Schlüssel ebenfalls nicht hilft
Präzision bei den Grenzen zählt genauso viel wie bei den Stärken, denn ein Schlüssel ist kein Allzweckschild.
Er schützt keine bereits ausgestellte Sitzung. Wenn Schadsoftware auf deinem Rechner ein Sitzungs-Cookie stiehlt, nachdem du dich legitim angemeldet hast, liegt der Anmeldeschritt hinter dir und der Schlüssel ist nicht mehr beteiligt.
Er schützt nicht den Wiederherstellungspfad. Ein Konto, das per E-Mail oder durch einen Support-Mitarbeiter zurückgesetzt werden kann, ist nur so stark wie dieser Pfad. Genau deshalb ist das E-Mail-Konto das erste, das man schützt, und genau deshalb bleiben Sicherheitsfragen zur Kontowiederherstellung ein weiches Ziel.
Er schützt nicht das, was ein kompromittiertes Gerät sieht. Ist der Endpunkt vollständig kompromittiert, sitzt der Angreifer mit dir in der authentifizierten Sitzung.
Er deckt keine Dienste ab, die ihn nicht unterstützen. Das ist für die meisten Menschen die praktische Grenze und der Grund, warum ein Schlüssel eine Ergänzung zur Authenticator-App ist und kein Ersatz.
Die Nuance, die die meisten Vergleiche weglassen
An dieser Stelle schießt viel Sicherheitsliteratur über das Ziel hinaus, deshalb sei es klar gesagt.
Verifier-Impersonation-Resistance wird im NIST-Rahmenwerk nur auf AAL3 verlangt. Auf AAL1 und AAL2 ist sie nicht vorgeschrieben. Eine TOTP-App ist damit für einen sehr großen Teil gewöhnlicher Konten ein konformer zweiter Faktor, und sie bleibt eine deutliche Verbesserung gegenüber SMS-Codes oder gegenüber gar keinem zweiten Faktor.
Die ehrliche Formulierung lautet also nicht "Apps sind kaputt". Sie lautet: Apps haben eine spezifische Schwäche, nämlich Echtzeit-Phishing, und diese Schwäche ist struktureller Natur und kein Fehler einer bestimmten App. Kein Update deiner Authenticator-App wird sie beheben, denn die Lücke steckt im Schritt der manuellen Eingabe selbst.
Entscheiden, ohne es zu überdenken
Die Entscheidung folgt daraus, was ein Angreifer bekommt, wenn ein bestimmtes Konto fällt.
Setze einen Sicherheitsschlüssel dort ein, wo eine Kompromittierung nicht wiedergutzumachen ist. Zuerst dein E-Mail-Konto, denn es ist der Passwort-Rücksetzpfad für alles andere. Dann dein Passwort-Manager. Dann alles Finanzielle, das Schlüssel unterstützt.
Behalte die App für die Breite. Die meisten Dienste unterstützen weiterhin keine Sicherheitsschlüssel. Eine Authenticator-App auf diesen Konten ist weit besser als nichts, und sie kostet nichts.
Betreibe keinen einzelnen Schlüssel ohne Rückfallebene. Registriere einen zweiten, oder bewahre Wiederherstellungscodes ausgedruckt und offline auf. Den einzigen Schlüssel zu verlieren ist eine selbst verursachte Aussperrung, und das passiert häufiger, als gephisht zu werden.
Wenn du überlegst, welchen Schlüssel du kaufen sollst, vergleichen wir die aktuellen Modelle in unserem Vergleich der Hardware-Sicherheitsschlüssel.
Gegenüberstellung
| Authenticator-App | Sicherheitsschlüssel | |
|---|---|---|
| Widersteht Echtzeit-Phishing | Nein, gemäß NIST 5.2.5 | Ja, Antwort an die Sitzung gebunden |
| Was du handhabst | Einen Code, den du abliest und abtippst | Nichts, das Gerät signiert |
| Auf AAL3 verlangt | Allein nicht ausreichend | Erfüllt die Anforderung |
| Funktioniert bei den meisten Diensten | Ja | Nur wo unterstützt |
| Kosten | Kostenlos | Etwa 25 bis 60 Währungseinheiten pro Schlüssel |
| Hauptsächlicher Fehlerfall | Du wirst dazu gebracht, einen gültigen Code einzugeben | Du verlierst den Schlüssel ohne registrierte Sicherung |
| Wiederherstellung nach Verlust | Neuinstallation aus einer Sicherung der Seeds | Einen zweiten Schlüssel registrieren, oder Wiederherstellungscodes |
Die letzten beiden Zeilen werden am meisten unterschätzt. Das dominierende reale Risiko bei einer App ist, dazu verleitet zu werden, sie im falschen Moment korrekt zu benutzen. Das dominierende reale Risiko bei einem Schlüssel ist, ihn zu verlieren, nachdem man nur einen registriert hat.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Bewahre die Wiederherstellungscodes dort auf, wo du sie noch haben wirstWiederherstellungscodes sind das, was dich wieder hineinbringt, wenn ein Schlüssel verloren geht. Ein Passwort-Manager hält sie fern von dem Gerät, das du gerade wiederherstellen willst, und genau darum geht es.→Die Kurzfassung
Die Phishing-Frage ist keine Meinungssache. NIST hält fest, dass OTP-Authentifikatoren nicht als verifier-impersonation-resistant gelten können, und begründet es: die manuelle Eingabe bindet den Code nicht an die Sitzung. Ein Sicherheitsschlüssel signiert die Sitzung selbst, es gibt also nichts weiterzureichen.
Doch die Anforderung gilt auf AAL3, nicht überall. Eine Authenticator-App bleibt für die meisten Konten ein legitimer zweiter Faktor. Setze Schlüssel dort ein, wo ein Verlust nicht wiedergutzumachen wäre, behalte die App für den langen Rest, und sorge dafür, dass du einen Weg zurück hast.
Die hier beschriebenen Definitionen und Anforderungen stammen aus der NIST Special Publication 800-63B, und die Charakterisierung von passkeys aus dem eigenen Material der FIDO Alliance, beides zum Zeitpunkt des Schreibens geprüft. Standards werden überarbeitet; prüfe gegen den aktuellen Text, bevor du dich auf eine bestimmte Klausel stützt. Kommerzielle Links tragen das Attribut rel="sponsored nofollow"; eine Affiliate-Provision kann anfallen, ohne Mehrkosten für dich.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Ein Manager mit integrierter 2FA & Passkeys → NordPassTOTP & Passkeys speichern · XChaCha20 · Gratis-Tarif→Häufig gestellte Fragen
Ist ein Sicherheitsschlüssel wirklich phishing-resistenter als eine Authenticator-App?
In genau diesem Punkt ist der Standard eindeutig. NIST SP 800-63B hält fest, dass Authentifikatoren, die die manuelle Eingabe einer Ausgabe erfordern, etwa Out-of-Band- und OTP-Authentifikatoren, nicht als verifier-impersonation-resistant gelten dürfen, weil die manuelle Eingabe die Ausgabe nicht an die konkret authentifizierte Sitzung bindet. Ein kryptografischer Authentifikator signiert eine Kanalkennung zusammen mit seiner Antwort. Genau das tut ein Sicherheitsschlüssel, und genau das kann ein sechsstelliger Code nicht.
Warum ist das Abtippen des Codes so entscheidend?
Weil der Code nicht weiß, wo du ihn eintippst. NIST beschreibt den Angriff direkt: ein gefälschter Verifier kann die OTP-Ausgabe an den echten Verifier weiterspielen und sich erfolgreich authentifizieren. Eine gefälschte Login-Seite sammelt deinen Code ein und verwendet ihn innerhalb seines Gültigkeitsfensters. Der Code ist gültig, die Seite nicht, und nichts im Ablauf bemerkt den Unterschied.
Heißt das, Authenticator-Apps sind unsicher?
Nein, und hier lohnt sich Genauigkeit. Verifier-Impersonation-Resistance wird im NIST-Rahmenwerk nur auf AAL3 verlangt. Auf AAL1 und AAL2 ist sie nicht vorgeschrieben, eine TOTP-App bleibt also für einen großen Teil gewöhnlicher Konten ein konformer zweiter Faktor. Sie ist eine sehr große Verbesserung gegenüber SMS und gegenüber gar keinem zweiten Faktor. Die Lücke ist eng umrissen: es geht um Echtzeit-Phishing, nicht um die allgemeine Stärke der Methode.
Was macht einen Sicherheitsschlüssel widerstandsfähig, wo ein Code es nicht ist?
Der Credential ist kryptografisch statt eine abgeschriebene Zahl. Die FIDO Alliance beschreibt passkeys so, dass sie gängige Public-Key-Kryptografie nutzen, um phishing-resistente Authentifizierung zu ermöglichen. Die Antwort erzeugt das Gerät und sie ist an die Sitzung gebunden, es gibt also nichts, was du vorlesen könntest, und nichts, was ein Angreifer weiterreichen kann.
Sollte ich beides nutzen?
Das ist meist die praktische Antwort. Nutze einen Sicherheitsschlüssel für die Konten, deren Verlust am schlimmsten wäre, typischerweise E-Mail und Passwort-Manager, denn die E-Mail ist der Rücksetzpfad für alles andere. Behalte eine Authenticator-App für die vielen Dienste, die keine Schlüssel unterstützen. Registriere einen zweiten Schlüssel oder bewahre Wiederherstellungscodes offline auf, denn ein einziger Schlüssel ohne Rückfallebene ist ein Risiko eigener Art.
