Passwortlose Anmeldung mit FIDO2 und WebAuthn

Von John Fontana, Denver (US/CO)

Die FIDO (Fast Identity Online) Alliance und das World Wide Web Consortium (W3C) haben gemeinsam einen offenen Authentifizierungsstandard geschaffen, der passwortbasierte Anmeldeverfahren durch eine starke Authentifizierung auf Basis eines asymmetrischen (Public-Key-) Kryptosystems ersetzen soll. Genau genommen umfasst FIDO2 eigentlich zwei Standards: das „Client to Authenticator Protocol“ (CTAP2) der FIDO Alliance und die „Web Authentication API“ (WebAuthn) des W3C.

Die Ursprünge gehen auf den 2011 von Yubico und Google entwickelten FIDO „Universal 2nd Factor“ (U2F) zurück, der ebenfalls als offener Standard für starke Authentifizierung sorgen sollte. Sein Design basierte auf den Grundprinzipien Benutzerfreundlichkeit, Phishingresistente Sicherheit und dem Fehlen gemeinsamer Geheimnisse (Shared Secrets) zwischen den verschiedenen Diensten. Zur Weiterentwicklung dieser Spezifikation wurde 2013 die FIDO Alliance gegründet.

Überblick

Die heutigen FIDO2-Standards (https://fidoalliance.org/fido2/) basieren auf dem gleichen Public-Key-Kryptografie-Modell wie U2F – CTAP2 fügt jedoch zusätzliche Anwendungsfälle der Authentifizierung hinzu, wie beispielsweise eine passwortlose Anmeldung und die Benutzerverifizierung mit einer PIN oder biometrischen Merkmalen.

Die Public-Key-basierte Kryptografie bei FIDO vermeidet es, Geheimnisse (Schlüssel, Passwörter usw.) mit zentralen Systemen „teilen“ zu müssen – und so Credentials zum potenziellen Ziel von Angreifern zu machen. Bei FIDO2 steht der genutzte geheime Schlüssel (Private Key) unter der Kontrolle des Benutzers und verlässt nie das Authentifizierungsgerät – auch Informationen zur Benutzerverifizierung (PIN oder biometrische Daten) verlassen zu keiner Zeit den Authentifikator und werden niemals an den aufgerufenen Dienst gesendet. Stattdessen benötigt der Server des Dienstes nur den öffentlichen Schlüssel des Benutzers, der für sich genommen für die Authentifizierung nutzlos ist (vgl. Abb. 1). Es wird lediglich mittels des geheimen Schlüssels eine digitale Signatur erzeugt, die dessen Besitz nachweist – diese Signatur wird an den Authentifizierungsserver gesendet und dort mithilfe des öffentlichen Schlüssels validiert, um zu beweisen, dass eine Transaktion gültig beziehungsweise ein Anwender authentisch ist.

Bausteine von FIDO2

Bei der FIDO-Authentifizierung gibt es drei Hauptkomponenten: den Authentifikator, den Client / die Plattform und den
Server des Dienstes / die Relying Party (vgl. Abb. 2). Damit alle drei Komponenten richtig miteinander kommunizieren können, nutzt die FIDO2-Authentifizierung CTAP2+ sowie die WebAuthn-Spezifikation, die ursprünglich ebenfalls die FIDO
Alliance entwickelt hatte, bevor sie dem W3C zur Standardisierung zur Verfügung gestellt wurde.

WebAuthn ist eine logische Ergänzung für Webbrowser und die Familie der W3C-Standards: Diese API erleichtert die Erstellung und Verwendung FIDO-basierter Anmeldedaten für den Zugriff auf webbasierte Dienste. Google Chrome, Microsoft Edge und Mozilla Firefox unterstützen die WebAuthn API bereits, Apple testet das in seinem Browser Safari.

Das CTAP2-Protokoll ermöglicht es Benutzern, sich bei Diensten mit einem hardwaregestützten externen Authentifikator anzumelden, der mit einem mobilen Gerät oder einem Desktop-Computer kommuniziert. Das Protokoll nutzt zur Übertragung USB, Near-Field-Communication (NFC) und/oder Bluetooth und unterstützt auch U2F, um Abwärtskompatibilität zu gewährleisten. Da sich die FIDO Alliance auf hardware- und clientbasierte technische Sicherheitsanforderungen fokussiert, erscheint es folgerichtig, dass die Entwicklung von CTAP2 in ihren Händen verbleibt.

Per WebAuthn können Benutzer bei einer Website oder einem Dienst (Relying Party) einen öffentlichen Schlüssel registrieren und sich dort anschließend damit authentifizieren, indem sie nachweisen, über den entsprechenden geheimen Schlüssel zu verfügen (in einem FIDO-Authentifikator).

Die Registrierungs- und Authentifizierungsabläufe bei einer FIDO-Authentifizierung sind entscheidend, um Sicherheit und Datenschutz für den Benutzer zu gewährleisten. Es gibt verschiedene Kontrollmechanismen, die nicht nur dazu beitragen, die Geheimsphäre und Anonymität des Benutzers zu schützen, sondern auch dazu, Phishing, Replay-Attacken und Man-in-the-Middle (MitM)-Angriffe zu verhindern. So verifiziert etwa der FIDO-Client (Webbrowser oder Plattform) bei der Registrierung einer Website den Ursprung (URL), damit der Benutzer nicht später missbräuchlich auf eine gefälschte Website gelenkt werden kann.

Registrierung

Die Registrierungssequenz besteht aus fünf verschiedenen Schritten (vgl. Abb. 3):

• Zuerst erzeugt der aufgerufene Dienst (Relying Party) einen Zufallswert (Challenge), um einem Replay-Angriff vorzubeugen. Wenn sich ein neuer Benutzer registrieren will, generiert der Dienst eine Benutzerkennung (User-Handle) in einer für Menschen nicht lesbaren Form – bei einem bestehenden Konto wird die bereits festgelegte Benutzerkennung verwendet. Der Dienst sendet diese Information an die Client-Plattform zusammen mit der RPID (Relying-Party-Identifier), in der Regel seiner Top-Level-Domain.
• Als Nächstes überprüft der Client den Ursprung der Seite, um sicherzustellen, dass es sich um eine gültige Subdomain der RPID handelt, die der aufgerufene Dienst angegeben hat – das verhindert Phishing und MitM-Angriffe. Wird die Seite akzeptiert, erstellt der Client ein Datenobjekt, das aus der Challenge des aufgerufenen Dienstes und dem Ursprung aus Sicht des Clients besteht. Aus diesen Daten wird ein Hashwert errechnet, der zusammen mit der RPID des aufgerufenen Dienstes und der erzeugten Benutzerkennung an den Authentifikator gesendet wird.
• Im dritten Schritt überprüft der Authentifikator die Anwesenheit und Zustimmung des Benutzers (durch eine Interaktion mit dem Authentifikator – z. B. durch Berühren), um eine Anmeldeinformation zu generieren, die Tracking verhindert und die Geheimsphäre schützt. Zugleich soll damit sichergestellt werden, dass tatsächlich ein Mensch an der Authentifizierung beteiligt ist und keine Malware mit dem Authentifikator interagieren kann.
• Im vierten Schritt erstellt der Authentifikator ein Schlüsselpaar aus einem öffentlichen und einem geheimen Schlüssel für den aufgerufenen Dienst (Relying Party) und signiert den Hashwert der Client-Daten sowie den neuen öffentlichen Schlüssel mit seinem Attestierungsschlüssel. Anschließend sendet der Authentifikator das Attestierungsobjekt an den Client zurück. Das Attestierungsobjekt enthält den Hashwert der Client-Daten und die RPID, die Anmelde-ID für die neue Anmeldeinformation, den öffentlichen Schlüssel für die neue Anmeldeinformation, die Attestierungssignatur und das Attestierungszertifikat des Authentifikators, das wiederum den öffentlichen Attestierungsschlüssel enthält. Der Client sendet all dies an den aufgerufenen Dienst (Relying Party), zusammen mit dem Datenobjekt, dessen Hash er zuvor an den Authentifikator übergeben hat. Dabei kann der öffentliche Schlüssel nicht dazu missbraucht werden, um Konten zwischen verschiedenen Websites zu korrelieren.
• Zum Schluss prüft der aufgerufene Dienst (Relying Party) die Attestierungssignatur: Dabei verifiziert er, ob es sich bei der Domain des ursprünglich angefragten Dienstes, den der Client festgestellt hat, tatsächlich um die richtige Domain handelt, was MitM-Angriffe verhindert – da die Information über die ursprünglich angefragte Domain Teil der signierten Client-Daten ist, lässt sie sich nicht fälschen. Auch die zurückgesandte Challenge wird verifiziert, sodass man eine Anfrage nicht unbemerkt erneut übertragen kann (auch hier verhindert eine digitale Signatur Fälschungen). Eine Überprüfung des Attestierungszertifikats des Authentifikators steht ebenfalls noch an. Wenn alles akzeptiert wird, registriert die Relying Party die Anmelde-ID und den öffentlichen (Anmelde-)Schlüssel für das Benutzerkonto.

Attestierung und Sicherheit

Die Attestierung ist ein wichtiger Teil des Registrierungsverfahrens, bei dem der Authentifikator seine Sicherheitseigenschaften gegenüber dem aufgerufenen Dienst nachweist. Eine Attestierungssignatur von einem vertrauenswürdigen Attestierungszertifikat gewährleistet, dass der zu registrierende geheime Schlüssel tatsächlich sicher gespeichert und verarbeitet wird. Zudem kann die Attestierung auch belegen, dass der Authentifikator Multi-Faktor-Authentifizierungsfunktionen unterstützt, etwa eine Verifizierung mit PIN oder biometrischen Daten.

Für Dienste mit höheren Sicherheitsanforderungen ist allerdings darauf hinzuweisen, dass Attestierungssignaturen in WebAuthn standardmäßig deaktiviert sind. Bei den meisten Websites geht es ja letztlich einfach darum, ein Authentifizierungsverfahren anzuwenden, das stärker ist als eine passwortbasierte Anmeldung – wie der Authentifikator implementiert ist, spielt dann kaum eine Rolle. Daher wird ein Browser die Attestierungssignatur nur dann zurücksenden, wenn der Dienst es ausdrücklich anfordert.

Wenn ein Dienst (Relying Party) eine hochsichere Multi-Faktor-Authentifizierung benötigt, darf die Attestierungssignatur jedoch nicht ignoriert werden – sonst ist nicht gewährleistet, dass der Authentifikator tatsächlich Multi-Faktor-Authentifizierungsverfahren durchführen kann, selbst wenn er dies angibt.

Authentifizierung

Die Gesamtstruktur der Authentifizierungssequenz ist im Wesentlichen die gleiche wie bei der Registrierungssequenz:

• Zuerst erzeugt der aufgerufene Dienst (Relying Party) eine Challenge und sendet diese zusammen mit seiner RPID sowie der Anmelde-ID, die beim Registrierungsprozess für das Benutzerkonto generiert wurde, an den Client.
• Der Client überprüft den Ursprung der Anfrage anhand der RPID, die vom aufgerufenen Dienst gesendet wurde. Dann erzeugt er ein Client-Datenobjekt, berechnet daraus einen Hashwert und sendet diesen sowie die RPID zusammen mit der Anmelde-ID an den Authentifikator.
• Mit der Anmelde-ID überprüft der Authentifikator die Anwesenheit und Zustimmung des Benutzers, um den zugehörigen geheimen Schlüssel abzurufen. Außerdem überprüft er, ob diese Anmeldeinformation tatsächlich für die aktuelle RPID erzeugt wurde.
• Der Authentifikator signiert die RPID und die gehashten Client-Daten – nunmehr aber mit dem geheimen Anmeldeschlüssel statt mit seinem Attestierungsschlüssel. Der Client erhält eine Signatur zusammen mit der ID der Anmeldeinformation, welche die Signatur erzeugt hat, und übergibt diese zusammen mit dem Client-Datenobjekt an den aufgerufenen Dienst.
• Zum Schluss verifiziert die Relying Party den Ursprung, die Challenge und die Signatur mithilfe des öffentlichen Anmeldeschlüssels, den der Dienst bei der Registrierung gespeichert hat. Wenn alles in Ordnung ist, ist die Authentifizierung erfolgreich abgeschlossen.

Vorteile

Einer der Hauptvorteile der Spezifikationen von FIDO2 und WebAuthn ist, dass sie mehrere Authentifizierungsoptionen unterstützen:

• Ein-Faktor-Authentifizierung mit einem FIDO2-kompatiblen Hardware-Authentifikator, der Benutzernamen und Passwörter ersetzt.
• Zwei-Faktor-Authentifizierung (2FA) mit einem FIDO U2F- oder FIDO2-Hardware-Authentifikator als zweitem Kriterium neben Benutzernamen und Passwort.
• Multi-Faktor-Authentifizierung (MFA) mit einem FIDO2-kompatiblen Hardware-Authentifikator sowie einer Benutzerverifizierung (z. B. PIN oder biometrische Daten), um Benutzernamen und Passwörter zu ersetzen.

Selbst eine Ein-Faktor-Anmeldung mit FIDO2 ist dabei sicherer als einige Formen der Zwei-Faktor-Authentifizierung (z. B. SMS), da es hierbei keine Geheimnisse gibt, die von einem Angreifer aus der Ferne abgegriffen und missbraucht werden könnten. Denn auch bei der Ein-Faktor-Authentifizierung mit FIDO2 kommt Public-Key-Kryptografie zum Einsatz. Der Wegfall von Benutzernamen und Passwort erhöht jedoch den Komfort.

Auch die Registrierungs- und Authentifizierungssequenzen des „Vorgängers“ U2F funktionieren in Zwei-Faktor-Authentifizierungsszenarien, die einen Benutzernamen und ein Passwort erfordern. Bei FIDO2 kommt der Benutzer jedoch während der Registrierungs- und Authentifizierungssequenz ohne Passwort aus.

Bei der erstmaligen Registrierung übergibt die Relying Party einen Benutzerkennungs-Parameter an den Authentifikator – danach wird die Benutzerkennung nicht mehr verwendet, weil sie im Authentifikator gespeichert ist. Wenn die Authentifizierungssequenz jedoch eingeleitet wird, ohne die Anmelde-ID zu senden, wird die Benutzerkennung an die Relying Party zurückgesandt, damit diese den Benutzer identifizieren kann, ohne einen Benutzernamen zu benötigen.

Die Benutzerkennung erfüllt also weitgehend die gleiche Funktion wie die Anmelde-ID. Der Unterschied ist jedoch, dass die Anmelde-ID vom Authentifikator gewählt wird, die Benutzerkennung dagegen von der Relying Party. Durch die Verwendung der Benutzerkennung anstelle der Anmelde-ID hat die Relying Party mehr Kontrolle über die Struktur ihrer Daten. Darüber hinaus lässt sich die Benutzerkennung mit mehreren Anmeldedaten verknüpfen, sodass der Benutzer mehrere Authentifikatoren mit einem einzigen Konto verbinden kann.

Multi-Faktor-Authentifizierung mit passwortloser Anmeldung

FIDO2 führt das Konzept der „Resident Keys“ ein, die eine sichere Multi-Faktor-Authentifizierung mit passwortfreier Anmeldung ermöglichen sollen: Diesem Konzept zufolge werden geheime Schlüssel im persistenten Speicher des sicheren Authentifikators gespeichert. Bei Resident Keys sind weder Benutzername noch Passwort erforderlich, da die Schlüssel zu den Anmeldedaten des Benutzers werden. Ein Benutzer kann einfach auf eine Login-Seite gehen, den Authentifikator anschließen und auf die Schaltfläche tippen, um sich anzumelden. Dies wird als Ein-Faktor-Authentifizierung bezeichnet. Wenn der Authentifikator eine PIN- oder biometrische Verifizierung unterstützt, ermöglicht er zudem auch eine hochsichere Multi-Faktor-Authentifizierung in einem zweistufigen Anmeldeverfahren ohne Passwörter.

Fazit

FIDO2 und WebAuthn sind bereits verfügbar. Viele bekannte Browser – Microsoft Edge, Mozilla Firefox und Google Chrome – unterstützen den Standard und etwa Microsoft-Konten weisen den Weg bei internetbasierten Diensten.

Im vergangenen Jahr gab es bisweilen Kritik an den damals vorliegenden Draft-Standards und ihren ersten Umsetzungen: So hatte eine Analyse der Paragon Initiative den Implementierungen in Chrome, Firefox und Edge den Einsatz möglicherweise angreifbarer Kryptografie unterstellt und von der Verwendung von ECDAA zunächst abgeraten (vgl. https://paragonie.com/blog/2018/08/security-concerns-surrounding-webauthn-don-t-implement-ecdaa-yet). Und eine Bachelorarbeit hatte einen Angriff auf das Authentifizierungsverfahren beschrieben (Abhilfe wurde bis zur Veröffentlichung bereits gefunden) und die unbedingte Resistenz gegenüber MitM-Attacken während der Registrierung widerlegt (http://elib.uni-stuttgart.de/handle/11682/10389). Obwohl teils in Medienberichten dieser Eindruck entstand, verstanden sich beide Einwürfe jedoch nicht als „Fundamentalkritik“ an dem neuen Verfahren, sondern als Analysen und Hinweise zur Verbesserung, die teils auch zeitnah zu Ergebnissen geführt hatten.

John Fontana ist Standards- and Identity-Analyst bei Yubico.