Ein Passwort beantwortet nur eine einzige Frage:

Kennst du das richtige Geheimnis?

Das ist besser als gar keine Zugangskontrolle, besitzt aber einen grundlegenden Nachteil. Wird das Passwort gestohlen, kopiert, erraten oder über eine Phishingseite abgegriffen, kann sich ein Angreifer gegenüber dem Dienst mit genau demselben Geheimnis ausgeben.

Multi-Faktor-Authentifizierung ergänzt deshalb weitere Nachweise.

Passwort
+
weiterer Faktor
↓
stärkere Authentifizierung

Und Passkeys gehen noch einen Schritt weiter. Sie ersetzen das klassische Prinzip des gemeinsam bekannten Passworts durch kryptografische Schlüssel, die an den jeweiligen Dienst gebunden sind. WebAuthn definiert dafür öffentliche Schlüssel-Anmeldedaten, die einem bestimmten Relying Party Identifier beziehungsweise einer bestimmten Webdomain zugeordnet werden. (W3C)

Damit existieren heute mehrere sehr unterschiedliche Sicherheitsmodelle unter Bezeichnungen wie:

2FA,

MFA,

Authenticator-App,

Sicherheitsschlüssel,

Passkey.

Sie erfüllen nicht alle dieselbe Aufgabe und bieten nicht denselben Schutz.

Was bedeutet Authentifizierung?

Authentifizierung beantwortet die Frage:

Bist du wirklich derjenige,
für den du dich ausgibst?

Ein Dienst kann dafür unterschiedliche Nachweise verlangen.

Beim klassischen Passwort:

Du kennst ein Geheimnis.

Bei einem Hardware-Sicherheitsschlüssel:

Du besitzt einen bestimmten
kryptografischen Authenticator.

Bei manchen Verfahren wird dieser Authenticator zusätzlich lokal mit PIN oder Biometrie aktiviert.

NIST unterscheidet dabei verschiedene Authentifikatortypen und betrachtet unter anderem Passwörter als „etwas, das du weißt“, physische beziehungsweise kryptografische Authenticatoren als „etwas, das du besitzt“ und biometrische Merkmale als mögliche Aktivierungsfaktoren in Verbindung mit einem physischen Authenticator. (NIST Pages)

Was bedeutet Zwei-Faktor-Authentifizierung?

Bei 2FA, also Two-Factor Authentication, werden zwei voneinander verschiedene Arten von Authentifizierungsnachweisen kombiniert.

Vereinfacht:

Faktor 1
+
Faktor 2
↓
Anmeldung

Ein typisches Beispiel:

Passwort
→ Wissen

Authenticator-App
→ Besitz

Das ist stärker als lediglich:

Passwort
+
zweites Passwort

Denn zwei Passwörter sind zwar zwei Geheimnisse, gehören aber beide derselben Faktorart an: Wissen. Zwei Schritte sind deshalb nicht automatisch zwei Faktoren. NIST definiert Multi-Faktor-Authentifizierung entsprechend über unterschiedliche Faktoren beziehungsweise über Multi-Faktor-Authenticatoren, die beispielsweise einen Besitzfaktor mit einem lokalen PIN oder biometrischen Aktivierungsfaktor kombinieren. (NIST Pages)

2FA und MFA sind nicht exakt dasselbe

2FA bedeutet konkret zwei Faktoren.

MFA, Multi-Factor Authentication, ist der allgemeinere Begriff und bedeutet:

mehrere unterschiedliche Faktoren.

2FA
→ genau zwei Faktorarten

MFA
→ mindestens mehrere Faktorarten

Im Alltag werden beide Begriffe häufig fast synonym verwendet, weil die meisten Systeme praktisch mit zwei Faktoren arbeiten.

Zwei Schritte bedeuten nicht zwangsläufig zwei Faktoren

Ein System könnte beispielsweise verlangen:

Passwort
↓
Sicherheitsfrage

Das sind zwei Schritte.

Aber beides basiert auf:

etwas, das du weißt

Damit wurde der grundlegende Faktor nicht gewechselt.

Ein wirklich zweiter Faktor soll gerade verhindern, dass ein einziger kompromittierter Typ von Geheimnis automatisch den gesamten Login öffnet.

Die klassischen Faktorarten

Für das Grundverständnis reichen drei Kategorien.

Etwas, das du weißt

Zum Beispiel:

Passwort,

PIN,

lokales Aktivierungsgeheimnis.

Wissen
→ im Kopf beziehungsweise bekanntes Geheimnis

Etwas, das du besitzt

Zum Beispiel:

Smartphone,

Hardware-Sicherheitsschlüssel,

kryptografisches Gerät.

Besitz
→ bestimmter Authenticator

Etwas, das du bist

Zum Beispiel:

Fingerabdruck,

Gesichtsmerkmal.

Im NIST-Modell wird Biometrie nicht einfach als frei stehender alleiniger Authenticator behandelt, sondern nur im Zusammenspiel mit einem physischen Authenticator eingesetzt. Die biometrische Prüfung kann beispielsweise lokal den Zugriff auf einen kryptografischen Schlüssel freigeben. (NIST Pages)

Warum hilft ein zweiter Faktor?

Angenommen, dein Passwort wird durch ein Datenleck bekannt.

Ohne MFA:

Angreifer kennt Passwort
↓
Login möglich

Mit zusätzlichem Faktor:

Angreifer kennt Passwort
↓
zweiter Faktor fehlt
↓
Login scheitert

CISA empfiehlt deshalb, MFA für Konten zu aktivieren, weil ein gestohlenes Passwort allein dann nicht ausreichen muss, um das Konto zu übernehmen. Gleichzeitig betont CISA, dass die einzelnen MFA-Verfahren unterschiedliche Sicherheitsniveaus besitzen. (cisa.gov)

Nicht jede MFA schützt gleich gut

Das ist eine der wichtigsten Aussagen des gesamten Artikels.

Folgende Verfahren können alle umgangssprachlich als „2FA“ erscheinen:

SMS-Code,

TOTP-Code,

Push-Freigabe,

Hardware-Sicherheitsschlüssel,

Passkey.

Technisch sind sie aber sehr unterschiedlich.

MFA aktiviert
≠
jede MFA gleich sicher

CISA unterscheidet ausdrücklich zwischen schwächeren MFA-Varianten und phishing-resistenten Verfahren und empfiehlt insbesondere FIDO/WebAuthn als Ziel für stärkere Authentifizierung. (cisa.gov)

SMS als zweiter Faktor

Ein sehr verbreitetes Verfahren funktioniert so:

Passwort eingeben
↓
Dienst sendet SMS-Code
↓
Code eingeben
↓
Login

Das ist grundsätzlich stärker als ein Passwort allein, weil zusätzlich der Zugriff auf die registrierte Telefonnummer beziehungsweise das entsprechende Gerät benötigt wird.

Doch das Verfahren besitzt Grenzen.

NIST behandelt Authentifizierung über das öffentliche Telefonnetz ausdrücklich als eingeschränktes Verfahren und verlangt unter anderem, bei der Nutzung Risikosignale wie SIM-Wechsel, Gerätewechsel oder Portierung der Telefonnummer zu berücksichtigen. (NIST Pages)

Warum SMS schwächer sein kann

Der Sicherheitsnachweis hängt teilweise an der Kontrolle über:

Telefonnummer
+
Mobilfunkkonto
+
SIM beziehungsweise Teilnehmeridentität

Wird eine Telefonnummer betrügerisch auf eine andere SIM beziehungsweise einen anderen Anschluss übertragen, kann ein Angreifer möglicherweise auch Authentifizierungscodes empfangen. Genau deshalb nennt NIST SIM-Wechsel und Nummernportierung ausdrücklich als Risikosignale beim SMS-basierten Verfahren. (NIST Pages)

Das bedeutet nicht:

SMS-MFA
→ nutzlos

sondern:

SMS-MFA
→ besser als Passwort allein,
aber nicht stärkste verfügbare Variante

CISA formuliert denselben Grundgedanken: Jede MFA ist grundsätzlich besser als gar keine, phishing-resistente MFA sollte jedoch das Ziel sein. (cisa.gov)

E-Mail-Code ist ebenfalls kein besonders starker zweiter Schutz

Ein zusätzlicher Code per E-Mail wirkt zunächst ähnlich wie SMS.

Das Problem:

Vielleicht wird das E-Mail-Konto selbst nur mit demselben beziehungsweise einem anderen Passwort geschützt.

Im NIST-Modell darf E-Mail deshalb nicht als Out-of-Band-Authentifizierungsverfahren eingesetzt werden; NIST nennt unter anderem die Möglichkeit eines nur passwortgeschützten Mailzugangs, Übertragungsrisiken und Umleitungsangriffe. E-Mail darf dort zwar für bestimmte Recovery- und Bestätigungsvorgänge eingesetzt werden, wird aber nicht als regulärer Out-of-Band-Authenticator akzeptiert. (NIST Pages)

Authenticator-App und TOTP

Eine weitere sehr verbreitete Variante ist die Authenticator-App.

Sie zeigt beispielsweise einen sechsstelligen Code:

482 913

Nach kurzer Zeit:

107 526

und danach:

731 844

Das Verfahren heißt häufig TOTP, Time-Based One-Time Password.

Der Standard RFC 6238 erzeugt solche Einmalcodes aus einem gemeinsamen geheimen Schlüssel und einem zeitabhängigen Wert. Der übliche Standard-Zeitschritt beträgt 30 Sekunden.

Wie funktioniert TOTP vereinfacht?

Beim Einrichten erhalten Dienst und Authenticator ein gemeinsames Geheimnis.

Dienst
↔
gemeinsamer geheimer Schlüssel
↔
Authenticator-App

Beide berechnen anschließend unabhängig voneinander einen Code aus:

geheimer Schlüssel
+
aktuellem Zeitfenster

Der Code muss nicht über Mobilfunk vom Server gesendet werden.

Smartphone offline
↓
TOTP kann trotzdem erzeugt werden

Der RFC verlangt, dass Generator und Prüfer dasselbe Geheimnis beziehungsweise eine entsprechende Ableitung kennen und denselben Zeitparameter verwenden.

Der TOTP-Einrichtungsschlüssel ist sehr wichtig

Wer den zugrunde liegenden geheimen Schlüssel kopiert, kann ebenfalls passende Codes erzeugen.

Deshalb sollte nicht nur der aktuelle sechsstellige Code geschützt werden, sondern besonders das langfristige TOTP-Geheimnis selbst.

Konzeptionell:

TOTP-Code
→ kurzlebig

TOTP-Seed
→ langfristiges Geheimnis

Der RFC verlangt für jeden Generator ein eigenes gemeinsames Geheimnis und empfiehlt dessen Schutz vor unbefugtem Zugriff.

TOTP ist stärker als ein Passwort allein – aber nicht phishing-resistent

Das ist die entscheidende Grenze.

Eine Phishingseite kann fragen:

Passwort:
__________

Authenticator-Code:
______

Der Nutzer trägt beide Werte ein.

Der Angreifer verwendet sie sofort beim echten Dienst.

Nutzer
↓
gefälschte Website
↓
Angreifer
↓
echte Website

Der Code ist zwar kurzlebig, kann innerhalb seines gültigen Zeitfensters aber weitergereicht werden. NIST klassifiziert OTP-Verfahren deshalb ausdrücklich als nicht phishing-resistent, weil ein manuell eingegebener Authenticator-Output nicht kryptografisch an die echte Sitzung beziehungsweise den echten Verifier gebunden ist. (NIST Pages)

Einmalcode bedeutet also nicht Phishing-Schutz

Das Missverständnis lautet häufig:

Code nur 30 Sekunden gültig
→ Phishing unmöglich

Tatsächlich:

Code nur 30 Sekunden gültig
→ Angreifer muss schnell sein

Ein automatisierter Phishing-Angriff kann genau das tun.

Push-MFA

Statt einen Zahlencode abzutippen, erscheint auf dem Smartphone eine Anfrage:

Anmeldeversuch bestätigen?

Zulassen
Ablehnen

Das ist bequem.

Doch einfache Push-Freigaben besitzen ein psychologisches Problem.

MFA-Fatigue

Ein Angreifer besitzt bereits das Passwort und löst immer wieder Push-Anfragen aus.

Anfrage
Anfrage
Anfrage
Anfrage
Anfrage

Irgendwann klickt der Nutzer vielleicht:

Zulassen

weil er glaubt, die Meldung sei legitim oder weil er die Benachrichtigungen loswerden möchte.

NIST verlangt deshalb, die Zahl beziehungsweise Frequenz von Push-Anfragen sinnvoll zu begrenzen. CISA empfiehlt, wenn phishing-resistente MFA noch nicht möglich ist, unter anderem Number Matching einzusetzen, um einfache Push-Bombardierung zu erschweren. (NIST Pages)

Was ist Number Matching?

Statt nur:

Zulassen?

zeigt die Loginseite beispielsweise eine Zahl.

37

Auf dem Smartphone muss genau diese Zahl ausgewählt beziehungsweise eingegeben werden.

Browser:
37

Smartphone:
Welche Zahl siehst du?
→ 37

Das zwingt den Nutzer, den konkreten Loginvorgang stärker mit der Push-Anfrage zu verbinden.

Es ist ein sinnvoller Schutz gegen blindes Wegklicken.

Aber auch das ist noch nicht dasselbe wie echte kryptografische Phishing-Resistenz. CISA betrachtet Number Matching ausdrücklich als Zwischenmaßnahme, wenn FIDO/WebAuthn noch nicht eingesetzt werden kann. (cisa.gov)

Was bedeutet phishing-resistent?

Ein phishing-resistentes Verfahren soll nicht davon abhängen, dass der Nutzer jede gefälschte Domain zuverlässig erkennt.

Das Authentifizierungsprotokoll selbst verhindert, dass ein gültiger Authentifizierungsnachweis für den echten Dienst an einen betrügerischen Dienst weitergegeben werden kann.

NIST definiert Phishing-Resistenz genau in diesem Sinn: Der Authenticator-Output beziehungsweise das Authentifizierungsgeheimnis soll nicht erfolgreich bei einem betrügerischen Verifier eingesetzt werden können, ohne sich auf die Aufmerksamkeit des Nutzers verlassen zu müssen. (NIST Pages)

Das ist ein fundamentaler Unterschied.

klassisches MFA:
Nutzer muss Phishing teilweise erkennen

gegen:

phishing-resistente Authentifizierung:
Protokoll blockiert falschen Verifier

Hardware-Sicherheitsschlüssel

Ein Hardware-Sicherheitsschlüssel ist ein physisches Gerät, das kryptografische Schlüssel speichern und für Authentifizierung verwenden kann.

Zum Beispiel über:

USB,

NFC,

andere geeignete Schnittstellen.

Konzeptionell:

Website
↓
kryptografische Herausforderung
↓
Sicherheitsschlüssel
↓
signierter Nachweis
↓
Website prüft Signatur

Bei modernen FIDO2/WebAuthn-Verfahren arbeitet der Dienst mit Public-Key-Kryptografie statt mit einem gemeinsam bekannten Passwortgeheimnis. NIST erkennt entsprechende kryptografische Authenticatoren als phishing-resistent an, wenn die zusätzlichen Anforderungen an die Bindung zum Verifier erfüllt sind. WebAuthn ist dabei ausdrücklich ein Beispiel für Verifier-Name-Binding. (NIST Pages)

Public Key und Private Key

Bei einem solchen Verfahren entsteht ein Schlüsselpaar:

Private Key
+
Public Key

Der Private Key bleibt beim Authenticator beziehungsweise im dafür vorgesehenen Credential-System.

Der Public Key kann beim Dienst gespeichert werden.

Gerät / Authenticator
→ Private Key

Dienst
→ Public Key

Bei der Anmeldung sendet der Dienst eine Herausforderung.

Der Authenticator signiert relevante Daten mit seinem privaten Schlüssel.

Der Dienst prüft die Signatur mit dem öffentlichen Schlüssel. WebAuthn beschreibt genau dieses Modell öffentlicher Schlüssel-Anmeldedaten und kryptografischer Assertions. (W3C)

Warum ist das besser als ein Passwort?

Bei einem Passwort besitzen beide Seiten im Prinzip eine Beziehung zu demselben Geheimnis.

Nutzer
→ Passwort

Server
→ muss Passwort verifizieren können

Bei Public-Key-Authentifizierung besitzt der Server dagegen nicht den privaten Schlüssel des Nutzers.

Server kompromittiert
↓
öffentlicher Schlüssel gestohlen
↓
damit lässt sich keine
gültige private Signatur erzeugen

Das beseitigt eine zentrale Klasse klassischer Passwortprobleme. FIDO beschreibt Passkeys deshalb als einzigartige kryptografische Schlüsselpaare, bei denen der private Schlüssel nicht vom jeweiligen Dienst gespeichert wird. (FIDO Alliance)

Was ist WebAuthn?

WebAuthn, Web Authentication, ist eine W3C-Spezifikation für Public-Key-basierte Authentifizierung in Webanwendungen.

Die aktuelle Level-3-Spezifikation beschreibt Public-Key-Credentials, die einem bestimmten Relying Party Identifier zugeordnet werden. Browser und Authenticator sorgen gemeinsam dafür, dass ein Credential nur im Kontext des zugehörigen Dienstes verwendet werden kann. Der Dienst wiederum muss bei Registrierung und Login die Herkunft, also den origin, prüfen. (W3C)

Vereinfacht:

example.com
↓
Credential für example.com

Eine gefälschte Website:

examp1e-login.example

kann nicht einfach denselben Credential-Kontext beanspruchen.

Genau deshalb hilft WebAuthn gegen Phishing

Bei einem klassischen OTP kann der Nutzer den Code von:

echte Website

versehentlich bei:

falsche Website

eingeben.

Der Code selbst enthält keine ausreichend starke Bindung an den echten Dienst.

Bei WebAuthn wird der kryptografische Vorgang hingegen an den Relying Party Identifier beziehungsweise den authentifizierten Webkontext gebunden. NIST führt WebAuthn deshalb ausdrücklich als Beispiel für phishing-resistente Authentifizierung über Verifier-Name-Binding an. (NIST Pages)

FIDO2 und WebAuthn

Die Begriffe werden oft gemeinsam genannt.

Das FIDO2-System verbindet im Wesentlichen:

WebAuthn auf Seiten der Webanwendung beziehungsweise des Browsers

und:

CTAP für die Kommunikation mit kompatiblen Authenticatoren.

Die FIDO Alliance beschreibt WebAuthn und CTAP gemeinsam als FIDO2. (FIDO Alliance)

Für einen normalen Nutzer reicht meist die vereinfachte Vorstellung:

Website / Browser
↓
WebAuthn
↓
Authenticator

Was ist ein Passkey?

Ein Passkey ist eine nutzerfreundlich verwaltete FIDO-basierte Public-Key-Anmeldeinformation.

Der Benutzer muss sich dabei kein Passwort merken.

Dienst
↓
Passkey registrieren
↓
kryptografisches Schlüsselpaar

Bei der späteren Anmeldung:

Dienst stellt Challenge
↓
Passkey wird aktiviert
↓
Signatur
↓
Dienst prüft Public Key

Passkeys sind für den jeweiligen Dienst beziehungsweise dessen Relying Party gebunden und dadurch gegen klassische Credential-Reuse- und Phishing-Probleme wesentlich robuster als Passwörter. (FIDO Alliance)

Das biometrische Merkmal wird nicht zum Passwort der Website

Das ist ein häufiges Missverständnis.

Beim Anmelden erscheint:

Fingerabdruck verwenden

oder:

Gesicht bestätigen

Daraus könnte man schließen:

Website bekommt meinen Fingerabdruck.

Bei FIDO-basierten Passkeys ist das nicht der Zweck. Die Biometrie dient typischerweise lokal dazu, die Nutzung des Authenticator-Schlüssels freizugeben. FIDO beschreibt ausdrücklich, dass biometrische Informationen bei FIDO-Authentifizierung das Gerät nicht verlassen. (FIDO Alliance)

Konzeptionell:

Fingerabdruck
↓
lokale Prüfung
↓
Private Key darf verwendet werden
↓
kryptografische Signatur
↓
Website

Die Website erhält also den kryptografischen Nachweis – nicht dein Fingerabdruckbild.

PIN und Passkey

Dasselbe Grundprinzip gilt für einen Geräte-PIN.

Der PIN kann lokal einen Authenticator aktivieren.

PIN
↓
Gerät entsperrt Credential-Nutzung
↓
Signatur

NIST unterscheidet solche lokalen Activation Secrets ausdrücklich von zentral verifizierten Passwörtern: Der lokale PIN wird nicht wie ein Webseitenpasswort an den entfernten Verifier übertragen. (NIST Pages)

Bedeutet ein Passkey automatisch Zwei-Faktor-Authentifizierung?

Nicht unbedingt in jeder technischen Einordnung.

Das ist eine wichtige Feinheit.

Ein kryptografischer Authenticator kann nach NIST als Single-Factor Cryptographic Authenticator funktionieren, wenn lediglich Besitz beziehungsweise Kontrolle des Schlüssels nachgewiesen wird.

Wird der Authenticator zusätzlich bei jeder Verwendung durch einen unabhängigen lokalen Faktor wie PIN oder Biometrie aktiviert, kann er als Multi-Factor Cryptographic Authenticator wirken. (NIST Pages)

Deshalb ist die Aussage:

Passkey
=
immer exakt 2FA

zu grob.

Richtiger:

Passkey
→ kryptografischer Authenticator

mit User Verification
→ kann mehrere Faktoren
innerhalb eines Authenticator-Vorgangs verbinden

Ein Login kann dadurch trotzdem einfacher werden

Klassische MFA:

Benutzername
↓
Passwortmanager öffnen
↓
Passwort einfügen
↓
Authenticator-App öffnen
↓
Code ablesen
↓
Code eintippen

Passkey:

Konto auswählen
↓
Gerät lokal entsperren
↓
fertig

Damit können weniger sichtbare Schritte zugleich ein technisch stärkeres Verfahren ergeben.

Sicherheit muss also nicht automatisch mehr Reibung bedeuten.

Was sind synchronisierte Passkeys?

Ein Passkey kann über einen geeigneten Credential-Provider zwischen eigenen Geräten synchronisiert werden.

Zum Beispiel konzeptionell:

Smartphone
    ↕
Credential-Synchronisierung
    ↕
Notebook

Dadurch muss der Nutzer nicht für jedes neue Gerät bei jedem Dienst einen komplett neuen Passkey registrieren. NIST SP 800-63B-4 berücksichtigt solche syncable authenticators inzwischen ausdrücklich; FIDO bezeichnet synchronisierte Passkeys als wichtige Consumer-Variante für geräteübergreifende Nutzung und vereinfachte Wiederherstellung. (NIST Pages)

Was sind gerätegebundene Passkeys?

Bei einem device-bound Passkey bleibt der private Schlüssel an einem bestimmten Authenticator beziehungsweise Gerät gebunden.

Beispiel:

Hardware-Sicherheitsschlüssel
↓
Private Key bleibt dort

Er wird nicht über eine Synchronisationsinfrastruktur auf andere Geräte kopiert.

FIDO unterscheidet solche gerätegebundenen Passkeys von synchronisierten Passkeys. Beide verwenden Public-Key-Kryptografie und sind stark phishing-resistent, unterscheiden sich jedoch unter anderem bei Portabilität, Recovery und Assurance. (FIDO Alliance)

Synchronisiert oder gerätegebunden – was ist besser?

Die Antwort hängt vom Risiko ab.

Synchronisierte Passkeys bieten großen Komfort:

neues Gerät
↓
Passkeys wieder verfügbar

Gerätegebundene Schlüssel bieten dagegen eine stärkere Bindung an einen konkreten physischen Authenticator.

NIST verlangt für das höchste Authentication Assurance Level AAL3 nicht exportierbare kryptografische Schlüssel; synchronisierbare Authenticator-Schlüssel gelten dagegen als exportierbar und kommen nach NIST für AAL2 oder darunter in Betracht. (NIST Pages)

Für normale Verbraucher- und viele Geschäftskonten kann Synchronisierung daher sehr attraktiv sein. Für besonders hoch abgesicherte administrative Zugänge können gerätegebundene Hardware-Authenticatoren sinnvoller sein.

Ein verlorenes Gerät muss nicht automatisch einen verlorenen Account bedeuten

Bei synchronisierten Passkeys kann ein anderes eigenes Gerät beziehungsweise die Credential-Synchronisierung den Zugang erhalten.

Bei gerätegebundenen Passkeys sollte dagegen häufig bewusst mehr als ein Authenticator registriert werden.

Sicherheitsschlüssel A
+
Sicherheitsschlüssel B

Dann ist einer:

Hauptschlüssel

und der andere:

Backup.

Der Grundgedanke ist derselbe wie bei Backups:

ein einziges Gerät
→ Single Point of Failure

Recovery wird mit stärkerer Authentifizierung wichtiger, nicht unwichtiger

Du schützt dein Konto hervorragend mit:

Hardware-Key,

Passkey,

MFA.

Dann verlierst du sämtliche registrierten Authenticatoren.

Nun entscheidet der Wiederherstellungsweg über den Zugang.

NIST behandelt Account Recovery deshalb als eigenständigen Sicherheitsprozess und kennt unter anderem gespeicherte Recovery-Codes, ausgegebene Recovery-Codes, Recovery-Kontakte und erneute Identitätsprüfung. (NIST Pages)

Recovery darf nicht viel schwächer als der Login sein

Stell dir vor:

Login:
Hardware-Key
+
PIN

aber:

Passwort vergessen:
Wie hieß dein Haustier?

Dann greift der Angreifer nicht die starke Authentifizierung an.

Er nimmt die schwache Seitentür.

starker Haupteingang
+
schwaches Recovery
=
schwaches Gesamtsystem

Deshalb müssen Authentifizierung und Wiederherstellung gemeinsam betrachtet werden.

Recovery-Codes

Viele Dienste stellen einmalige Notfallcodes bereit.

NIST betrachtet gespeicherte Recovery-Codes ausdrücklich als eigene Recovery-Methode und empfiehlt, solche Codes offline beziehungsweise sicher verwahrt aufzubewahren. Nach erfolgreicher Verwendung soll der verwendete Code ungültig werden. (NIST Pages)

Ein Recovery-Code ist deshalb kein unwichtiges Stück Papier.

Er kann im Ernstfall praktisch den Zugang zum Konto ersetzen.

Recovery-Code
≈
Notfallschlüssel

Recovery-Code nicht ausschließlich dort speichern, wo er selbst benötigt wird

Beispiel:

Der einzige Recovery-Code für deinen Passwortmanager liegt ausschließlich:

im Passwortmanager

Dann hilft er bei Verlust des Passwortmanagerzugangs nicht.

Dasselbe gilt bei einem MFA-System, dessen einziger Notfallcode ausschließlich auf dem verlorenen Smartphone gespeichert ist.

Ein sinnvoller Recovery-Plan vermeidet solche Kreise.

Welche MFA sollte ich wählen?

Eine praktische Reihenfolge kann so aussehen:

phishing-resistenter Passkey / FIDO-Key
↓
starke kryptografische MFA
↓
Authenticator-App / TOTP
↓
SMS
↓
nur Passwort

Das ist kein absoluter Qualitätsindex für jede denkbare Implementierung. Es beschreibt vielmehr die grundlegende Sicherheitsentwicklung: CISA empfiehlt phishing-resistente FIDO/WebAuthn-Verfahren als Ziel und bewertet andere MFA-Varianten als sinnvolle, aber schwächere Zwischenstufen. (cisa.gov)

Wenn ein Dienst nur SMS anbietet

Dann ist:

SMS-MFA

in der Regel sinnvoller als:

gar keine MFA

Man sollte Sicherheitsmaßnahmen nicht ablehnen, nur weil es bereits ein stärkeres Verfahren gibt.

Sobald eine stärkere Option verfügbar wird, kann man wechseln.

Wenn TOTP verfügbar ist

TOTP vermeidet die Abhängigkeit vom öffentlichen Telefonnetz und ist eine sinnvolle zusätzliche Schutzschicht gegen viele Passwortdiebstähle.

Trotzdem sollte man wissen:

TOTP
→ nicht phishing-resistent

NIST stellt dies ausdrücklich klar. (NIST Pages)

Wenn FIDO/WebAuthn verfügbar ist

Dann bietet das Verfahren einen wichtigen zusätzlichen Vorteil:

Der Authentifizierungsnachweis wird kryptografisch an den richtigen Verifier beziehungsweise Dienst gebunden.

falsche Domain
↓
kein gültiger Credential-Kontext

Genau diese Eigenschaft macht WebAuthn phishing-resistent. (NIST Pages)

Welches Konto sollte zuerst MFA bekommen?

Besonders kritisch sind Accounts, über die andere Systeme kontrolliert oder zurückgesetzt werden können.

Dazu gehören typischerweise:

zentrale E-Mail-Konten,

Passwortmanager,

Cloud-Identitäten,

Hosting,

Domainverwaltung,

Administratorzugänge,

Finanzkonten.

Der Grund ist einfach:

wichtiges Konto kompromittiert
↓
weitere Konten erreichbar

CISA empfiehlt MFA generell besonders für sensible persönliche und geschäftliche Konten. (cisa.gov)

Die E-Mail-Adresse bleibt ein Schlüsselaccount

Viele Dienste senden Passwort-Reset-Nachrichten per E-Mail.

Wer dein Mailkonto kontrolliert, kann deshalb möglicherweise versuchen, weitere Konten zurückzusetzen.

Daher ist:

E-Mail
→ starkes einzigartiges Passwort
→ MFA beziehungsweise Passkey

eine besonders wichtige Basis.

Der Passwortmanager ebenfalls

Im Passwortmanager liegen möglicherweise Zugangsdaten für zahlreiche weitere Dienste.

Daher:

Passwortmanager
↓
starke Master-Passphrase
+
zusätzliche Authentifizierung
+
Recovery-Plan

NIST empfiehlt für Passwortmanager ebenfalls MFA, sofern diese angeboten wird. (NIST Pages)

Administratorzugänge besonders stark schützen

Ein normales Benutzerkonto darf vielleicht:

Profil ansehen.

Ein Administrator:

Benutzer verändern,

Konfiguration ändern,

Daten exportieren,

Systeme verwalten.

mehr Berechtigung
↓
größerer möglicher Schaden
↓
höheres erforderliches Authentifizierungsniveau

CISA empfiehlt phishing-resistente MFA ausdrücklich insbesondere auch für sensitive administrative Zugänge. (cisa.gov)

Kann ein Angreifer einen TOTP-Code zweimal verwenden?

Ein OTP soll nur einmal akzeptiert werden. NIST verlangt, dass ein gültiger OTP- beziehungsweise Out-of-Band-Code nicht mehrfach erfolgreich verwendet wird. Dadurch entsteht Replay-Resistenz gegenüber einfachem Wiederverwenden eines bereits verbrauchten Codes. (NIST Pages)

Das löst allerdings das Echtzeit-Phishingproblem nicht.

Ein noch nicht verwendeter Code kann während seiner Gültigkeit sofort weitergeleitet werden.

Replay-Resistenz und Phishing-Resistenz sind verschiedene Dinge

Das ist eine wichtige technische Unterscheidung.

Replay-Resistenz
→ alten Nachweis später
nicht erneut verwenden

Phishing-Resistenz
→ gültigen Nachweis
nicht an falschen Verifier liefern

Ein TOTP kann replay-resistent sein, ohne phishing-resistent zu sein. NIST beschreibt genau diesen Unterschied. (NIST Pages)

Passkeys und Credential Stuffing

Credential Stuffing lebt davon:

Passwort aus Dienst A
↓
bei Dienst B testen

Ein Passkey ist dagegen für einen bestimmten Relying Party Kontext erstellt.

Passkey A
→ Dienst A

Passkey B
→ Dienst B

Es gibt damit kein gemeinsames Passwort, das bei mehreren Websites wiederverwendet werden kann. FIDO hebt diese Dienstbindung als eine der zentralen Sicherheitseigenschaften von Passkeys hervor. (FIDO Alliance)

Server-Leak bei Passkeys

Bei einem klassischen Passwortsystem kann eine gestohlene Passwortdatenbank für Offline-Angriffe interessant sein.

Bei Passkeys speichert der Dienst den öffentlichen Schlüssel.

Server:
Public Key

Der private Schlüssel bleibt beim Authenticator beziehungsweise dessen Credential-Infrastruktur.

Authenticator:
Private Key

Der öffentliche Schlüssel ist nicht das Geheimnis, mit dem sich der Nutzer gegenüber dem Dienst authentifiziert. Das verändert das Schadensmodell bei einem Server-Leak erheblich. (W3C)

Passkey bedeutet nicht, dass Geräteverlust unwichtig ist

Der private Credential-Zugriff befindet sich auf deinen Geräten beziehungsweise in deiner Credential-Synchronisierung.

Damit werden neue Fragen wichtig:

Wie ist das Smartphone geschützt?

Wie funktioniert Gerätesperre?

Wie funktioniert Synchronisierung?

Wie funktioniert Account Recovery des Credential-Providers?

Welche Backup-Authenticatoren existieren?

Passkeys entfernen bestimmte Passwortprobleme, aber nicht sämtliche Fragen rund um Geräte- und Kontosicherheit.

Biometrie kann nicht einfach geändert werden wie ein Passwort

Das ist ein weiterer Grund, biometrische Daten sorgfältig zu behandeln.

Wenn ein Passwort kompromittiert ist:

neues Passwort erstellen

Ein Fingerabdruck ist dagegen dauerhaft Teil der Person.

NIST verlangt deshalb, biometrische Daten als sensible persönliche Informationen zu schützen und bevorzugt im Authentifizierungskontext lokale Vergleiche gegenüber zentraler Speicherung. (NIST Pages)

Bei Passkeys ist lokale Biometrie gerade deshalb attraktiv

Der Fingerabdruck beziehungsweise die Gesichtserkennung muss nicht als zentrales Website-Geheimnis verteilt werden.

Er kann lokal den Zugriff auf den kryptografischen Schlüssel freigeben.

Biometrie
↓
lokale Freigabe
↓
Private Key
↓
Signatur

FIDO nennt explizit, dass biometrische Informationen bei seiner Authentifizierung das Gerät nicht verlassen. (FIDO Alliance)

Was ist besser: PIN oder Fingerabdruck?

Für die Sicherheit eines Passkey-Authenticators kommt es weniger darauf an, welche Methode sich subjektiv moderner anfühlt, sondern wie der lokale Authenticator und sein Aktivierungsmechanismus abgesichert sind.

NIST erlaubt bei Multi-Faktor-Kryptografie sowohl:

etwas, das du weißt
→ Aktivierungs-PIN

als auch:

etwas, das du bist
→ biometrische Aktivierung

zusätzlich zum Besitz des Authenticator-Schlüssels. (NIST Pages)

Muss ich mein Passwort löschen, sobald ich einen Passkey eingerichtet habe?

Nicht zwangsläufig.

Viele Dienste befinden sich in einer Übergangsphase und erlauben:

Passwort
oder
Passkey

Dann verbessert ein Passkey zwar den eigenen Loginweg, aber ein weiterhin vorhandenes schwaches Passwort kann eventuell eine alternative Angriffsmöglichkeit bleiben.

FIDO weist deshalb bei der Umstellung auf phishing-resistente Passkeys darauf hin, dass nicht nur der Passkey-Login selbst, sondern auch alternative Login- und Recovery-Wege berücksichtigt werden müssen. (FIDO Alliance)

Der schwächste erlaubte Loginweg kann entscheidend sein

Beispiel:

Passkey
→ sehr stark

aber daneben:

Passwort:
Sommer2026!

und:

SMS-Recovery

Ein Angreifer muss nicht den Passkey brechen.

Er greift den einfacheren Weg an.

Gesamtsicherheit
≈
nicht nur stärkster,
sondern auch schwächster
praktisch nutzbarer Zugangspfad

Recovery ist deshalb Teil der Passkey-Migration

Ein Dienst kann die Anmeldung perfekt gegen Phishing schützen und anschließend eine schwache Kontoübernahme über Recovery erlauben.

FIDO beschreibt die Umstellung zu vollständig phishing-resistenter Authentifizierung deshalb als einen Prozess, bei dem auch Recovery- und alternative Authentifizierungspfade abgesichert werden müssen. (FIDO Alliance)

Häufige Irrtümer zu 2FA und Passkeys

„2FA bedeutet einfach zwei Passwörter“

Nein. Zwei Geheimnisse derselben Faktorart ergeben nicht automatisch echte Zwei-Faktor-Authentifizierung.

„SMS ist wertlos“

Nein. SMS-MFA kann wesentlich besser sein als ein Passwort allein. Sie besitzt jedoch bekannte Einschränkungen und wird von NIST als eingeschränktes Verfahren behandelt. (NIST Pages)

„Authenticator-App schützt vollständig gegen Phishing“

Nein. Manuell eingegebene OTP-Codes sind laut NIST nicht phishing-resistent. (NIST Pages)

„Ein Code ist sicher, weil er nur 30 Sekunden gültig ist“

Er kann innerhalb dieses Zeitfensters in Echtzeit weitergeleitet werden.

„Push-MFA ist automatisch sicher“

Eine einfache Approve/Reject-Abfrage kann durch wiederholte Anfragen missbraucht werden. NIST empfiehlt eine Begrenzung von Push-Anfragen; CISA empfiehlt als Zwischenmaßnahme Number Matching. (NIST Pages)

„Ein Fingerabdruck wird an jede Website geschickt“

Bei FIDO-Passkeys verbleiben biometrische Informationen auf dem Gerät; die Website erhält den kryptografischen Nachweis. (FIDO Alliance)

„Passkey ist nur ein neues Wort für Passwort“

Nein. Passkeys verwenden Public-Key-Kryptografie und teilen kein klassisches Passwortgeheimnis mit dem Dienst. (W3C)

„Passkeys können bei Phishing einfach abgefangen werden“

WebAuthn bindet Credentials an den jeweiligen Relying Party Identifier beziehungsweise Webkontext und wird von NIST gerade deshalb als phishing-resistentes Verfahren eingeordnet. (NIST Pages)

„Jeder Passkey ist automatisch exakt zwei Faktoren“

Nein. Nach NIST kann kryptografische Authentifizierung je nach Authenticator und Aktivierung als Single-Factor oder Multi-Factor ausgeführt werden. (NIST Pages)

„Synchronisierte Passkeys sind immer genauso hoch abgesichert wie Hardware-Keys“

Nicht in jedem Assurance-Modell. NIST verlangt für AAL3 nicht exportierbare Schlüssel; synchronisierte Schlüssel sind definitionsgemäß exportierbar. (NIST Pages)

„Wenn ich Passkeys nutze, brauche ich keinen Recovery-Plan“

Gerade starke Authentifizierung braucht einen sauberen Wiederherstellungsweg. NIST behandelt Account Recovery deshalb als eigenen Sicherheitsprozess. (NIST Pages)

Ein praktischer Sicherheitsplan für Privatnutzer

Ein sehr robuster Weg lässt sich in wenigen Schritten aufbauen.

1. Passwortmanager verwenden
↓
2. für jedes Konto eigenes Passwort
↓
3. MFA aktivieren
↓
4. stärkste angebotene MFA wählen
↓
5. Passkeys bevorzugen, wenn sinnvoll verfügbar
↓
6. Recovery-Codes sicher verwahren

Damit muss nicht jedes Konto sofort technisch perfekt werden.

Die Sicherheitslage verbessert sich trotzdem deutlich.

Kritische Konten zuerst

Priorität haben insbesondere:

zentrale E-Mail,

Passwortmanager,

Cloudkonto,

Finanzkonten,

Domain- und Hostingverwaltung,

Administratorzugänge.

Dort möglichst:

Passkey / FIDO

oder zumindest:

Passwort
+
starke MFA

Ein praktischer Plan für Unternehmen

Bei Organisationen sollte die Strategie nicht lauten:

MFA irgendwie aktivieren.

Sondern:

Konten klassifizieren
↓
Risiko bewerten
↓
phishing-resistente MFA priorisieren
↓
Recovery absichern
↓
alte schwächere Loginwege reduzieren

CISA empfiehlt Organisationen ausdrücklich den Übergang zu phishing-resistenter MFA, insbesondere FIDO/WebAuthn, und nennt dies auch für sensible administrative Zugänge als Ziel. (cisa.gov)

Administratoren können Hardware-Keys erhalten

Für hochkritische Systeme kann ein Ansatz beispielsweise lauten:

Administrator
↓
gerätegebundener Sicherheitsschlüssel
↓
PIN / User Verification
↓
FIDO/WebAuthn

Zusätzlich:

zweiter registrierter
Backup-Schlüssel

Damit kann der private Schlüssel stark an physische Hardware gebunden werden, während gleichzeitig der Geräteverlust berücksichtigt wird.

Normale Mitarbeiter können andere Passkey-Modelle verwenden

Bei geringerem beziehungsweise mittlerem Risiko können synchronisierte Passkeys einen sehr guten Kompromiss aus:

Phishing-Resistenz,

Komfort,

Gerätewechsel,

Recovery

bieten. FIDO unterscheidet ausdrücklich zwischen synced und device-bound Passkeys und sieht unterschiedliche Einsatzbereiche je nach benötigtem Assurance-Niveau. (FIDO Alliance)

Die Authentifizierungsstrategie sollte nicht statisch bleiben

Ein Unternehmen kann heute mit:

Passwort
+
TOTP

arbeiten.

Später:

Passwort
+
FIDO-Key

und schließlich:

Passkey
ohne klassisches Passwort

Die Entwicklung muss nicht in einem einzigen Schritt erfolgen.

Was sollte eine Website heute unterstützen?

Aus Betreiberperspektive ist der wichtigste Grundsatz:

Nicht nur Passwortlogin als ewigen Endzustand betrachten.

Eine moderne Authentifizierungsarchitektur kann langfristig verschiedene Credentialtypen unterstützen.

bestehende Nutzer
→ Passwort + MFA

modernisierte Nutzer
→ Passkey

besonders kritische Konten
→ stärkere gerätegebundene Authenticatoren

WebAuthn bietet dafür eine standardisierte API für Public-Key-Credentials im Web. (W3C)

HTTPS ist dabei Voraussetzung

WebAuthn ist für sichere Webkontexte ausgelegt. Die W3C-Spezifikation verlangt für reguläre Webursprünge einen sicheren HTTPS-Kontext; localhost besitzt eine spezielle Entwicklungs-Ausnahme. (W3C)

Das verbindet den Authentifizierungsbereich direkt mit SSL und HTTPS.

Der Server muss den Origin prüfen

WebAuthn allein schützt nicht gegen jede fehlerhafte Implementierung.

Der Dienst muss unter anderem kontrollieren, ob die Authentifizierungsantwort tatsächlich für den erwarteten Origin beziehungsweise Relying Party Kontext erzeugt wurde. Die WebAuthn-Spezifikation verlangt ausdrücklich die Validierung des origin. (W3C)

Das zeigt erneut:

sicherer Standard
+
falsche Implementierung
≠
automatisch sicheres System

Challenge-Response verhindert einfaches Wiederverwenden

Der Dienst erzeugt bei einer Authentifizierung eine neue Herausforderung.

Server
↓
zufällige Challenge
↓
Authenticator
↓
signiert Kontext
↓
Server prüft

Eine alte Authentifizierungsantwort soll dadurch nicht einfach für einen neuen Login erneut verwendbar sein. WebAuthn enthält entsprechende kryptografische Challenge-Daten; NIST fordert bei kryptografischen Authenticatoren ebenfalls frische Nonces beziehungsweise Challenges für Replay-Resistenz. (W3C)

Passkeys sind deshalb mehr als Komfort

Auf den ersten Blick sieht die Innovation aus wie:

Passwort tippen
↓
durch Fingerabdruck ersetzen

Technisch ist die Veränderung wesentlich tiefer:

geteiltes Geheimnis
↓
wird ersetzt durch
↓
Public-Key-Kryptografie
+
Dienstbindung
+
lokale Authenticator-Aktivierung

Das ist der eigentliche Fortschritt.

Der Nutzer muss weniger Geheimnisse bewegen

Bei Passwörtern und OTP:

Nutzer liest Geheimnis
↓
Nutzer überträgt Geheimnis
↓
Website bekommt Geheimnis

Bei WebAuthn:

Authenticator besitzt Schlüssel
↓
führt kryptografische Operation aus
↓
Website erhält Nachweis

Der Nutzer muss keinen geheimen sechsstelligen Code von A nach B übertragen.

Genau dadurch verschwindet eine wesentliche Angriffsfläche klassischer Phishing-Angriffe. (NIST Pages)

Der beste Faktor ist der, der tatsächlich konsequent verwendet wird

Sicherheit muss im Alltag funktionieren.

Ein hochkomplexes Verfahren, das Benutzer ständig umgehen, schafft neue Probleme.

Passkeys sind deshalb besonders interessant, weil starke kryptografische Authentifizierung teilweise sogar einfacher als Passwort plus OTP sein kann.

mehr Sicherheit
+
weniger Eingabe

müssen kein Widerspruch sein.

Was du dir über 2FA merken solltest

Zwei Schritte sind nicht automatisch zwei Faktoren.

Passwort
+
Sicherheitsfrage
→ zweimal Wissen

Dagegen:

Passwort
+
Authenticator
→ unterschiedliche Faktoren

MFA schützt insbesondere davor, dass ein gestohlenes Passwort allein zur Kontoübernahme genügt. CISA empfiehlt deshalb MFA generell, weist aber ausdrücklich darauf hin, dass nicht alle MFA-Methoden denselben Schutz bieten. (cisa.gov)

Was du dir über OTP merken solltest

SMS- und TOTP-Codes verbessern den Schutz gegenüber reinem Passwortlogin erheblich.

Sie besitzen aber eine gemeinsame wichtige Grenze:

Code
→ wird vom Nutzer übertragen

Dadurch kann eine Phishingseite den Code unter Umständen in Echtzeit an den echten Dienst weiterleiten.

NIST klassifiziert sowohl OTP- als auch Out-of-Band-Authentifizierung deshalb nicht als phishing-resistent. (NIST Pages)

Was du dir über Passkeys merken solltest

Passkeys verwenden ein anderes Grundmodell.

Private Key
→ beim Authenticator

Public Key
→ beim Dienst

Der Authenticator beweist den Besitz des privaten Schlüssels kryptografisch.

WebAuthn bindet die Anmeldeinformation an den passenden Dienst beziehungsweise Relying Party Kontext. (W3C)

Darum können Passkeys phishing-resistent sein.

falsche Website
↓
falscher Relying-Party-Kontext
↓
kein gültiger WebAuthn-Nachweis

NIST nennt WebAuthn ausdrücklich als Beispiel für phishing-resistente Authentifizierung. (NIST Pages)

Was du dir über Biometrie merken solltest

Bei Passkeys wird dein Fingerabdruck nicht zum Passwort einer Website.

Fingerabdruck / Gesicht
↓
lokale Prüfung
↓
Credential aktivieren
↓
kryptografischer Nachweis

FIDO sieht vor, dass biometrische Informationen das Gerät nicht verlassen. (FIDO Alliance)

Was du dir über synchronisierte Passkeys merken solltest

Sie können zwischen eigenen Geräten verfügbar gemacht werden.

Gerät A
↕
Credential-Synchronisierung
↕
Gerät B

Das verbessert Komfort und Recovery.

Gerätegebundene Passkeys halten den privaten Schlüssel dagegen auf einem konkreten Authenticator und können für besonders hohe Assurance-Anforderungen geeigneter sein. NIST berücksichtigt synchronisierbare Authenticatoren inzwischen ausdrücklich, verlangt für AAL3 jedoch nicht exportierbare Schlüssel. (NIST Pages)

Die Sicherheitsentwicklung in einer Linie

Der gesamte Authentifizierungsweg lässt sich so zusammenfassen:

ein Passwort
↓
einzigartiges Passwort
↓
Passwortmanager
↓
Passwort + MFA
↓
stärkere MFA
↓
phishing-resistente FIDO/WebAuthn-Authentifizierung
↓
Passkeys

Nicht jeder Dienst befindet sich heute auf derselben Stufe.

Deshalb ist eine pragmatische Strategie sinnvoll:

stärkste verfügbare
und praktikable Methode verwenden

statt:

auf perfekte Zukunft warten
und heute nichts aktivieren

Der zentrale Merksatz lautet:

Multi-Faktor-Authentifizierung macht einen gestohlenen Passwortfaktor weniger mächtig. Passkeys gehen weiter: Sie ersetzen das gemeinsam bekannte Passwortgeheimnis durch dienstgebundene Public-Key-Kryptografie. Genau deshalb können FIDO/WebAuthn-Verfahren nicht nur stärker, sondern zugleich einfacher zu bedienen und wesentlich widerstandsfähiger gegen Phishing sein.