FIDO2 im Detail: WebAuthn, Passkeys und Sicherheit erklärt (DE)

FIDO2 umfasst zwei Public-Key-Authentifizierungsstandards: die Web Authentication API (WebAuthn) des World Wide Web Consortiums und das FIDO Alliance Client to Authenticator Protocol (CTAP). Zusammen ermöglichen sie einer Relying Party, einen kryptografischen Nachweis zu registrieren und zu verwenden, ohne ein wiederverwendbares gemeinsames Geheimnis wie ein Passwort zu speichern.

FIDO2 kann eine Phishing-resistente und Replay-resistente Authentifizierung bereitstellen, wenn es korrekt implementiert und validiert wird. Es beweist nicht die rechtliche Identität einer Person, entscheidet nicht, wer sich registrieren darf, sichert keine kompromittierte Serversitzung und repariert keinen schwachen Kontowiederherstellungsprozess. Dies sind angrenzende Kontrollen, die um den Authentifizierungsablauf herum konzipiert werden müssen.

Wichtige Erkenntnisse

• FIDO2 ist WebAuthn plus CTAP. WebAuthn verbindet eine Website oder Anwendung mit dem Client; CTAP verbindet die Client-Plattform mit einem Roaming-Authenticator.
• Der private Schlüssel bleibt beim Authenticator. Die Relying Party speichert einen öffentlichen Schlüssel und überprüft Signaturen über neue Challenges und einen spezifischen Kontext.
• Die Domänenbindung schafft Phishing-Resistenz. Ein für eine Relying-Party-Kennung registrierter Nachweis kann nicht einfach an die nicht verwandte Domäne eines Angreifers weitergeleitet werden.
• Passkeys sind FIDO-Nachweise. Sie können gerätegebunden oder über die Geräte eines Anbieters synchronisiert werden, was unterschiedliche Kompromisse bei der Sicherheit, Wiederherstellung und Portabilität mit sich bringt.
• Die Wiederherstellung ist Teil des Sicherheitsmodells. Eine starke FIDO2-Anmeldung kann umgangen werden, wenn E-Mail-, Support- oder Identitätswiederherstellungspfade den Nachweis durch schwächere Beweise ersetzen können.

Was ist FIDO2?

Die Übersicht der FIDO Alliance Spezifikationen definiert FIDO2 als die Kombination der W3C WebAuthn-Spezifikation und der FIDO Client to Authenticator Protocols. Die Standards unterteilen das System in zusammenarbeitende Rollen:

• Relying Party: die Website oder der Dienst, der Nachweise registriert und Authentifizierungs-Assertions überprüft.
• Client: normalerweise die Browser- oder Betriebssystemkomponente, die WebAuthn implementiert und den Ablauf vermittelt.
• Authenticator: eine Plattformkomponente oder ein externes Gerät, das den Nachweisschlüssel erstellt und verwendet.
• Benutzer: die Person, die der Registrierung oder Authentifizierung zustimmt und sich lokal mit einer PIN, einem Passwort oder einem Biometrie-Merkmal verifizieren kann.

Die W3C WebAuthn Level 3 Spezifikation definiert eine Web-API zum Erstellen und Verwenden von Public-Key-Nachweisen, die auf eine Relying Party zugeschnitten sind. Skripte empfangen niemals den privaten Nachweisschlüssel. Sie empfangen strukturierte Daten und kryptografische Beweise, die über den Authenticator und den Client erzeugt werden.

FIDO2, WebAuthn, CTAP, U2F und Passkeys im Vergleich

Begriff	Praktische Bedeutung	Hauptabgrenzung
FIDO2	Die WebAuthn- und CTAP-Standards zusammen verwendet	Komplette Standardsfamilie, nicht ein API-Aufruf
WebAuthn	Browser- oder Client-API und Relying-Party-Datenmodell für Public-Key-Nachweise	Verbindet die Relying Party mit dem Client
CTAP2	Protokoll zwischen der Client-Plattform und einem Roaming-Authenticator	Überträgt die Kommunikation externer Authenticatoren über Transportschichten wie USB, NFC und BLE
U2F / CTAP1	Früheres FIDO-Protokoll, häufig mit Sicherheitsschlüsseln für den zweiten Faktor verbunden	Begrenzter als moderne FIDO2-Funktionen
Passkey	Ein auffindbarer FIDO-Nachweis, der für die passwortlose Anmeldung entwickelt wurde	Kann synchronisiert oder gerätegebunden sein
Sicherheitsschlüssel	Ein Roaming-Hardware-Authenticator, der über USB, NFC oder eine andere unterstützte Transportschicht verbunden ist	Eine mögliche Authenticator-Form
Plattform-Authenticator	In ein Gerät oder Betriebssystem integrierter Authenticator	Oft mit lokaler PIN oder Biometrie aktiviert

„Passwortlos“ beschreibt den Benutzerpfad, nicht jede mögliche Implementierung. Ein Dienst kann WebAuthn als zweiten Faktor nach einem Passwort, als primären Multi-Faktor-Nachweis oder zusammen mit anderen Authenticatoren verwenden. Die Relying Party muss entscheiden, welche Nachweiseigenschaften und Flags die Sicherheit der geschützten Aktion erfüllen.

Wie die FIDO2-Registrierung funktioniert

Die Registrierung, auch als Nachweiserstellung bezeichnet, bindet einen neuen Public-Key-Nachweis an ein Konto bei der Relying Party.

1. Der Server erstellt Registrierungsoptionen

Die Relying Party generiert eine neue, unvorhersehbare Challenge und sendet Optionen zur Public-Key-Nachweiserstellung an den Client. Die Optionen identifizieren die Relying Party, das Benutzerkonto, akzeptierte Algorithmen, Authenticator-Präferenzen, Attestierungspräferenzen und gegebenenfalls ausgeschlossene bestehende Nachweis-IDs.

Challenges sollten einmalig, kurzlebig, an die richtige Sitzung und den richtigen Benutzer gebunden und vom Server gespeichert oder überprüfbar sein. Eine nur im Browser generierte Challenge kann den Serverablauf nicht schützen.

2. Der Client ruft WebAuthn auf

Die Anwendung ruft navigator.credentials.create() mit den Public-Key-Optionen auf. Der Browser überprüft Ursprung und Sicherheitskontext und fordert dann einen verfügbaren Authenticator auf, einen Nachweis zu erstellen.

3. Der Authenticator holt die Benutzerzustimmung ein

Der Authenticator erfordert die Anwesenheit des Benutzers und, falls angefordert und unterstützt, die Benutzerverifizierung. Die Anwesenheit des Benutzers kann eine Berührung oder eine explizite Aktion sein. Benutzerverifizierung bedeutet, dass der Authenticator den Benutzer lokal über eine PIN, ein Gerätes geheimnis, ein Biometrie-Merkmal oder eine andere unterstützte Methode verifiziert.

Ein lokales Biometrie-Merkmal entsperrt normalerweise die Verwendung des Nachweises; die Biometrie-Vorlage wird nicht als Authentifizierungsgeheimnis an die Website gesendet.

4. Der Authenticator erstellt ein Schlüsselpaar

Der Authenticator erstellt ein Nachweis-Schlüsselpaar, das auf die Relying Party zugeschnitten ist. Der private Schlüssel bleibt durch den Authenticator oder dessen Synchronisationsinfrastruktur geschützt. Der resultierende Nachweis enthält den öffentlichen Schlüssel, die Nachweis-ID, Authenticator-Daten, Client-Daten und Attestierungsinformationen gemäß dem ausgewählten Format.

5. Der Server validiert und speichert den Nachweis

Die Relying Party validiert den Ablauf, bevor sie etwas speichert. Die Überprüfungen umfassen:

• erwartete Challenge;
• erwarteter Ursprung;
• korrekter Relying-Party-Bezeichner-Hash;
• erwarteter Cross-Origin-Status und topOrigin, wenn der Ablauf eingebettet ist;
• Benutzerpräsenz- und Benutzerverifizierungs-Flags gemäß Richtlinie;
• akzeptierte Algorithmen und Schlüsselparameter;
• Attestierungsstruktur und Vertrauensrichtlinie, falls Attestierung angefordert wird;
• Eindeutigkeit und Zuordnung zum korrekten Benutzerkonto.

Der Server speichert die Nachweis-ID, den öffentlichen Schlüssel, die Kontobindung, den Signaturzähler oder den anwendbaren Status, Transporte oder Metadaten, wo nützlich, und Informationen zum Nachweislebenszyklus. Er benötigt niemals den privaten Schlüssel.

Wie die FIDO2-Authentifizierung funktioniert

Die Authentifizierung beweist die Kontrolle über einen zuvor registrierten Nachweis.

1. Der Server erstellt Anforderungsoptionen

Die Relying Party generiert eine neue Challenge und sendet Assertionsoptionen. Sie kann eine Positivliste von Nachweis-IDs enthalten oder auffindbare Nachweise verwenden, damit der Authenticator das Konto identifizieren kann.

2. Der Client fordert eine Assertion an

Die Anwendung ruft navigator.credentials.get() auf. Der Browser und der Authenticator wählen einen geeigneten Nachweis aus und holen die erforderliche Benutzerpräsenz oder lokale Benutzerverifizierung ein.

3. Der Authenticator signiert die Ablaufsdaten

Der Authenticator signiert den neuen Challenge-Kontext und die Authenticator-Daten mit dem privaten Nachweisschlüssel. Da der Nachweis auf die Relying Party zugeschnitten ist, kann ein nicht verwandter Phishing-Ursprung den Authenticator nicht dazu auffordern, eine gültige Assertion für den echten Dienst zu erstellen.

4. Der Server überprüft die Assertion

Die Relying Party überprüft die erwartete Challenge, den Ursprung, den Relying-Party-Hash, die Signatur mit dem gespeicherten öffentlichen Schlüssel, erforderliche Flags, den zulässigen Nachweis, die Benutzerbindung und den relevanten Zähler oder Sicherungsstatus. Erst dann sollte sie eine Anwendungssitzung erstellen oder erhöhen.

Jede Assertion beweist die Kontrolle zu einem bestimmten Zeitpunkt. Sitzungserstellung, Tokenschutz, Reauthentifizierung, Transaktionsautorisierung, Abmeldung und Widerruf bleiben separate Anwendungsverantwortlichkeiten.

Warum FIDO2 Phishing-resistent ist

Passwörter und Einmalcodes können auf einer Betrüger-Website eingegeben werden, die sie an den echten Dienst weiterleiten kann. FIDO2 verwendet einen Nachweis, der auf die Relying Party zugeschnitten ist, und bindet die Assertion kryptografisch an den erwarteten Verifiziererkontext.

Die NIST SP 800-63B-4 Authenticator-Anforderungen beschreiben WebAuthn als Phishing-resistent durch Verifizierer-Namen-Bindung. Die Authenticator-Ausgabe ist an den authentifizierten Domänennamen gebunden, anstatt davon abzuhängen, dass der Benutzer eine betrügerische Seite bemerkt.

Phishing-Resistenz hat Grenzen:

• Sie stoppt keine Malware oder einen Angreifer, der bereits eine authentifizierte Sitzung kontrolliert.
• Sie verhindert nicht, dass ein Benutzer eine bösartige Transaktion innerhalb des echten Dienstes genehmigt.
• Sie sichert keinen Kontowiederherstellungspfad, der den Nachweis ersetzen kann.
• Sie beweist nicht, dass die Person, die den Authenticator kontrolliert, die reale Person ist, die eine Organisation registrieren wollte.

Replay-Resistenz und Challenge-Behandlung

Eine aufgezeichnete Assertion sollte in einem späteren Ablauf nicht funktionieren, da jede Anforderung eine neue Challenge verwendet. NIST beschreibt kryptografische Authenticatoren, die Nonces oder Challenges enthalten, als Replay-resistent.

Implementierungsfehler können diese Eigenschaft aufheben. Häufige Fehler sind vorhersehbare Challenges, Wiederverwendung von Challenges, Akzeptieren einer Challenge für das falsche Konto, Nichtdurchsetzung des Ablaufs oder Validierung nur der Signatur unter Missachtung des Ursprungs- und Relying-Party-Kontextes.

Der Server sollte eine Challenge atomar als verbraucht markieren. Wenn parallele Anfragen gleichzeitig eingehen, sollte nur ein erfolgreicher Ablauf diese Challenge verwenden können.

Benutzerpräsenz und Benutzerverifizierung

WebAuthn unterscheidet:

• Benutzerpräsenz (UP): Der Benutzer hat eine Interaktion durchgeführt, die eine Beteiligung anzeigt.
• Benutzerverifizierung (UV): Der Authenticator hat den Benutzer lokal über einen Aktivierungsfaktor wie eine PIN oder ein Biometrie-Merkmal verifiziert.

Allein die Präsenz ist keine Multi-Faktor-Authentifizierung. Ein Dienst, der eine risikoreichere Aktion schützt, kann das UV-Flag erfordern und Assertions ablehnen, die nur Präsenz zeigen. Anforderungen sollten die erwarteten Flag-Werte angeben, anstatt sich auf eine Oberflächenbezeichnung wie „Face ID verwenden“ zu verlassen.

Die Qualität der lokalen Verifizierung variiert auch je nach Authenticator. Die Relying Party hat möglicherweise nur begrenzte Einblicke in die genaue Biometrie- oder PIN-Implementierung für vom Benutzer bereitgestellte Authenticatoren, daher sollte die Richtlinie proportional zur Transaktion und zur Bereitstellungspopulation sein.

Plattform-, Roaming- und geräteübergreifende Authenticatoren

Plattform-Authenticatoren

Diese sind in ein Telefon, Laptop oder Betriebssystem integriert. Sie können einen kurzen Ablauf über die lokale Entsperrmethode des Geräts ermöglichen. Der Kompromiss ist die Abhängigkeit von der Plattform-Kontowiederherstellung, der Gerätesicherheit und dem Synchronisationsverhalten.

Roaming-Authenticatoren

Externe Sicherheitsschlüssel können zwischen Geräten mitgeführt und über unterstützte Transportschichten verbunden werden. Sie sind nützlich für Anwendungsfälle in der Belegschaft, Administration oder mit hoher Sicherheit, insbesondere wenn die Nicht-Exportierbarkeit von Nachweisen und die verwaltete Ausgabe wichtig sind.

Geräteübergreifende Authentifizierung

Hybride Abläufe können ein nahe gelegenes Telefon verwenden, um eine Sitzung auf einem anderen Gerät zu authentifizieren. Die Übergabe- und Nähemechanismen verbessern die Benutzerfreundlichkeit, fügen aber Details zur Benutzeroberfläche und zum Bedrohungsmodell hinzu, die getestet werden sollten, anstatt sie als identisch mit der Authentifizierung auf demselben Gerät zu behandeln.

Unterstützen Sie mehrere Nachweise pro Konto. Benutzer ersetzen Telefone, verlieren Sicherheitsschlüssel, verwenden Arbeits- und persönliche Geräte und benötigen eine sichere Möglichkeit, Nachweise zu benennen, zu überprüfen und zu entfernen.

Gerätegebundene und synchronisierte Passkeys

Ein Passkey ist ein FIDO-Nachweis, der für die Anmeldung ohne Passwort entwickelt wurde. Passkeys können sein:

• Gerätegebunden: Der private Nachweisschlüssel bleibt an einen Authenticator oder ein verwaltetes Gerät gebunden.
• Synchronisiert: Nachweismaterial wird verschlüsselt und über die Infrastruktur eines Anbieters synchronisiert, um auf berechtigten Geräten verwendet zu werden.

Synchronisierte Passkeys verbessern die Verfügbarkeit und Wiederherstellung, während gerätegebundene Nachweise eine stärkere Nicht-Exportierbarkeit bieten können. Die NIST SP 800-63B-4 Richtlinie für synchronisierbare Authenticatoren erlaubt synchronisierbare Authenticatoren in Kontexten bis zur Authentifizierungs-Sicherheitsstufe 2, wenn ihre Anforderungen erfüllt sind, aber die Synchronisierung kollidiert mit der Nicht-Exportierbarkeit, die auf Stufe 3 erforderlich ist.

Leiten Sie die Sicherheit nicht vom Wort „Passkey“ ab. Bewerten Sie, ob die Nachweise gesichert, für die Sicherung geeignet, geteilt, verwaltet, gerätegebunden, attestiert und mit Benutzerverifizierung gemäß der Richtlinie der Relying Party aktiviert sind.

Attestierung und Authenticator-Vertrauen

Die Attestierung kann Beweise über die Herkunft oder Eigenschaften eines Authenticator bei der Registrierung liefern. Sie ist nicht dasselbe wie die Authentifizierungssignatur und identifiziert nicht den menschlichen Benutzer.

Verbraucherdienste minimieren oft die Attestierungssammlung aus Gründen des Datenschutzes und der Ökosystemkompatibilität. Verwaltete Unternehmensimplementierungen können spezifische Authenticator-Modelle oder Zertifizierungen erfordern. Die Entscheidung sollte eine Frage des Bedrohungsmodells beantworten, anstatt standardmäßig geräteidentifizierende Beweise zu sammeln.

Wenn Attestierung verwendet wird:

• definieren Sie akzeptierte Formate und Vertrauensanker;
• validieren Sie Zertifikatspfade und -aussagen korrekt;
• spezifizieren Sie die Aktualisierung von Metadaten und die Widerrufsbehandlung;
• planen Sie für Authenticatoren ohne vertrauenswürdige Attestierung;
• dokumentieren Sie Datenschutz- und Aufbewahrungsfolgen;
• testen Sie den Ersatz, wenn ein akzeptiertes Modell seinen Status ändert.

FIDO2 ersetzt nicht die Identitätsprüfung

FIDO2 beweist die Kontrolle über einen Nachweis, der bei einer Relying Party registriert ist. Es legt nicht den rechtlichen Namen, das Alter, die Adresse, den regulatorischen Status oder die reale Einzigartigkeit der Person fest, die ihn registriert.

Diese Unterscheidung führt zu drei gängigen Mustern:

1. Pseudonyme Registrierung: Der Dienst benötigt ein sicheres Konto, aber keine verifizierte reale Identität.
2. Identitätsgebundene Registrierung: Die Identitätsprüfung erfolgt zuerst, dann wird ein FIDO-Nachweis an das verifizierte Konto gebunden.
3. Step-up oder Wiederherstellung: Der Dienst überprüft die Identität erneut oder verwendet andere starke Beweise, bevor ein verlorener Authenticator ersetzt werden darf.

Die Bindung sollte explizit sein. Halten Sie fest, welches Konto und welcher Prüfstatus beim Hinzufügen des Nachweises vorlagen, welche Sitzung ihn autorisiert hat und ob ein späteres Risiko eine erneute Authentifizierung oder Identitätsaktualisierung auslösen sollte.

Kontowiederherstellung und Nachweislebenszyklus

Die Wiederherstellung ist der Punkt, an dem viele Phishing-resistente Implementierungen abgewertet werden. Wenn ein Benutzer jeden FIDO-Nachweis über einen E-Mail-Link oder schwache Support-Fragen ersetzen kann, wird ein Angreifer stattdessen diesen Pfad angreifen.

Ein vollständiger Lebenszyklus umfasst:

• Hinzufügen eines zweiten Authenticator;
• Benennen und Anzeigen registrierter Nachweise;
• Geräteverlust und vermutete Kompromittierung;
• Widerruf eines Nachweises, ohne das Konto zu zerstören;
• Wiederherstellung mit Codes, einem anderen Authenticator, verwaltetem Support oder Identitätsprüfung;
• Benachrichtigung des Benutzers über einen unabhängigen Kanal;
• Verzögerung oder Einschränkung risikoreicher Aktionen nach der Wiederherstellung;
• Protokollierung, wer den Nachweissatz geändert hat und warum;
• Schließen von Sitzungen, die vor der Meldung der Kompromittierung erstellt wurden.

Die Wiederherstellungssicherheit sollte den Konsequenzen des Ersetzens des Authenticator entsprechen. Ein Community-Konto mit geringem Risiko und ein Administrator, der Gelder verschieben kann, benötigen nicht denselben Pfad.

So bewerten Sie eine FIDO2-Implementierung

Protokollvalidierung

Testen Sie die Challenge-Generierung und den Ablauf, die genaue Ursprungsvalidierung, die Regeln für Relying-Party-Bezeichner, die Signaturprüfung, unterstützte Algorithmen, die UP- und UV-Richtlinie, die Nachweiszuordnung, Zähler, Backup-Flags und die Fehlerbehandlung. Bevorzugen Sie eine gewartete Serverbibliothek gegenüber einer manuellen Binäranalyse, verstehen Sie aber dennoch, was sie validiert.

Authenticator-Abdeckung

Testen Sie Plattform- und Roaming-Authenticatoren über unterstützte Browser, Betriebssysteme, Geräte, Transportschichten, Unternehmensrichtlinien und Barrierefreiheitseinstellungen. Schließen Sie die Nachweiserstellung, Anmeldung, bedingte Benutzeroberfläche, geräteübergreifende Nutzung und Geräteaustausch ein.

Konto- und Sitzungssicherheit

Überprüfen Sie, wer einen Nachweis hinzufügen kann, ob eine kürzliche Authentifizierung erforderlich ist, wie Sitzungen erhöht werden, wann eine Reauthentifizierung erfolgt und wie sich Nachweisänderungen auf bestehende Sitzungen auswirken.

Wiederherstellung und Support

Führen Sie Red-Teaming-Übungen für Verlust, gestohlene Geräte, kompromittierte E-Mails, SIM-Kartenwechsel, Support-Impersonation und böswilligen Haushalts- oder Arbeitsplatzzugriff durch. Messen Sie sowohl die Angreiferresistenz als auch den Abschluss durch echte Benutzer.

Datenschutz und Beobachtbarkeit

Minimieren Sie die Attestierungs- und Gerätedaten auf das, was die Richtlinie benötigt. Vermeiden Sie die Verwendung stabiler Nachweis-IDs über Relying Partys hinweg; die Scoping-Funktion von WebAuthn ist darauf ausgelegt, dies zu verhindern. Protokollieren Sie Gründe und Ablaufergebnisse, ohne sensible Client-Daten preiszugeben.

Häufige Fehler bei der FIDO2-Implementierung

Überprüfung der Signatur, aber nicht des Kontextes

Eine gültige Signatur ist unzureichend, wenn der Server die Challenge, den Ursprung, den Relying-Party-Bezeichner, die Flags und die Kontobindung nicht exakt überprüft.

Jeden Passkey als Multi-Faktor bezeichnen

Der Server muss überprüfen, ob eine Benutzerverifizierung stattgefunden hat und ob die Nachweiseigenschaften der Richtlinie entsprechen. Allein die Benutzerpräsenz ist nicht dasselbe wie eine lokale Benutzerverifizierung.

Zulassen einer stillen Nachweisergänzung

Das Hinzufügen eines neuen Authenticator ändert die Kontosicherheit. Erfordern Sie eine angemessene kürzliche Authentifizierung oder einen Wiederherstellungsablauf, benachrichtigen Sie den Benutzer und protokollieren Sie das Ereignis.

Nur einen Nachweis unterstützen

Konten mit einem einzigen Nachweis schaffen eine brüchige Wiederherstellung und fördern schwächere Fallbacks. Ermöglichen Sie mehrere Authenticatoren mit klarer Verwaltung und Widerruf.

Das Passwort als gleichwertigen Fallback belassen

Wenn ein Passwort den FIDO-Pfad immer umgehen kann, existiert die Phishing-Resistenz möglicherweise nur auf dem bevorzugten Button. Beschränken oder entfernen Sie schwächere Pfade entsprechend dem Risiko und dem Migrationsstadium.

Serversitzungen ignorieren

FIDO2 authentifiziert den Anmeldeablauf. Schützen Sie Cookies und Tokens, rotieren Sie Sitzungen nach der Authentifizierung, erfordern Sie ein Step-up für sensible Aktionen und widerrufen Sie kompromittierte Sitzungen.

Eine Checkliste für die Bereitstellung

Bestätigen Sie vor dem Start, dass:

• Challenges unvorhersehbar, einmalig, kurzlebig und an die richtige Sitzung gebunden sind;
• Ursprung, Relying-Party-Bezeichner, Signatur, Algorithmus, Flags und Nachweisbesitz validiert werden;
• UP- und UV-Anforderungen für jede geschützte Aktion explizit sind;
• Plattform-, Roaming-, synchronisierte, gerätegebundene und geräteübergreifende Fälle wie unterstützt getestet werden;
• Benutzer mehrere Nachweise registrieren und sie sicher benennen, überprüfen und widerrufen können;
• Nachweisergänzung und Wiederherstellung eine proportionale Sicherheit erfordern und Benachrichtigungen generieren;
• die Attestierungssammlung eine definierte Vertrauens-, Datenschutz- und Metadatenrichtlinie hat;
• Passwort-, Einmalcode-, Support- und Identitätswiederherstellungs-Fallbacks einem Bedrohungsmodell unterzogen wurden;
• authentifizierte Sitzungen und Transaktionsautorisierung separat geschützt sind;
• Protokollbibliotheken, Browser-Unterstützung, Veralterungen und Sicherheitsereignisse Verantwortliche haben.

Wo Didit neben FIDO2 passt

FIDO2 handhabt die Authentifizierung, nachdem ein Nachweis registriert wurde. Didit kann die angrenzende Identitätsentscheidung durch ID-Verifizierung, Liveness Detection und Biometrische Authentifizierung unterstützen. Der veröffentlichte Preis für die Biometrische Authentifizierung beträgt 0,10 $ pro Überprüfung.

Teams können die aktuellen Modulpreise auf der Preisseite einsehen. Es sollte nicht angenommen werden, dass diese Produkte FIDO2 aus dieser Beschreibung implementieren: Der architektonische Punkt ist, dass Identitätsprüfung, biometrische Überprüfungen, FIDO-Nachweisauthentifizierung, Kontowiederherstellung und Anwendungsautorisierung unterschiedliche Vertrauensentscheidungen sind.

Häufig gestellte Fragen

Wofür steht FIDO2?

FIDO steht für Fast Identity Online. FIDO2 ist die Standardsfamilie, die W3C WebAuthn mit FIDO Alliance CTAP für die Public-Key-Authentifizierung kombiniert.

Ist FIDO2 dasselbe wie WebAuthn?

Nein. WebAuthn definiert die Relying-Party- und Client-API sowie das Datenmodell. FIDO2 umfasst WebAuthn plus CTAP, das die Client-Plattform mit Roaming-Authenticatoren verbindet.

Sind Passkeys FIDO2-Nachweise?

Ja. Passkeys sind auffindbare FIDO-Nachweise, die für die passwortlose Anmeldung entwickelt wurden. Sie können über berechtigte Geräte synchronisiert werden oder gerätegebunden bleiben.

Ist FIDO2 Phishing-resistent?

Eine ordnungsgemäß validierte FIDO2-Authentifizierung ist Phishing-resistent, da der Nachweis auf die Relying Party zugeschnitten ist und die Assertion an diesen Verifiziererkontext gebunden ist. Eine schwache Wiederherstellung oder eine bereits kompromittierte Sitzung kann den beabsichtigten Schutz dennoch umgehen.

Verwendet FIDO2 Biometrie?

Es kann eine lokale Biometrie verwenden, um einen Authenticator zu aktivieren und die Benutzerverifizierung einzustellen. Die Relying Party empfängt normalerweise das Ergebnis und die kryptografische Assertion, nicht die Biometrie-Vorlage.

Verifiziert FIDO2 die Identität einer Person?

Nein. Es verifiziert die Kontrolle über einen registrierten Nachweis. Die reale Identitätsprüfung ist eine separate Registrierungs- oder Wiederherstellungsentscheidung, wenn der Dienst dies erfordert.

Was passiert, wenn ein Benutzer jeden Authenticator verliert?

Der Dienst benötigt eine Wiederherstellungsrichtlinie, die dem Kontorisiko angemessen ist. Optionen können ein anderer registrierter Authenticator, Wiederherstellungscodes, verwaltete administrative Wiederherstellung oder erneute Identitätsprüfung sein, mit Benachrichtigung und Einschränkungen nach der Wiederherstellung.

Primäre Referenzen

• FIDO Alliance Spezifikationen zur Benutzerauthentifizierung
• W3C Web Authentication Level 3 Candidate Recommendation Snapshot
• FIDO Alliance CTAP 2.3 Proposed Standard
• NIST SP 800-63B-4: Authentifizierung und Authenticator-Verwaltung
• NIST SP 800-63B-4 Authenticator-Anforderungen

FIDO2 ersetzt wiederverwendbare Verifizierer-Geheimnisse durch auf den Bereich zugeschnittene Public-Key-Nachweise und neue kryptografische Abläufe. Sein Wert bleibt nur erhalten, wenn die Relying Party den vollständigen Kontext validiert, den Nachweislebenszyklus verwaltet, Sitzungen und sensible Aktionen schützt und der Wiederherstellung die gleiche Sicherheitsaufmerksamkeit wie der Anmeldung schenkt.