© Bla.zej Lyjak, 123RF

Naht dank Fido-2-Authentifizierung mit Webauthn das Ende des Passwortzeitalters? Die Mischung aus offenem W3C-Standard, Konzernen, Open Source und großen Hardwareherstellern deutet in diese Richtung.

Fido war eine treue Seele. Der Mischling war der Lincoln-Familie zugelaufen und schnell zum Familienmitglied geworden. Dreckige Pfoten, auf dem Sofa schlafen – alles war dem Hund erlaubt. Sogar das Schicksal seines Herrchen teilte er: Nur wenige Monate nach dem tödlichen Attentat auf den US-Präsidenten Abraham “Abe” Lincoln erschoss ihn ein Betrunkener (Abbildung 1, [1]). Kein Wunder, dass der Name Fido sprichwörtlich für einen treuen, vertrauenswürdigen Partner steht, nicht nur im englischen Sprachraum [2].

Abbildung 1: Treu bis in den Tod: Abraham Lincolns Hund Fido.

Auch Fidonet [3], ein Bulletin-Board-System-Netzwerk (BBS) aus den 80er und 90er Jahren, erwählte einen Hund mit einer Diskette im Maul zu seinem Logo (Abbildung 2). Das Fido-Netz war bei Hackern und Geeks außerordentlich beliebt, schlummerte dann aber mit dem Aufkommen des WWW ein und fristet seit ungefähr 2006 nur mehr ein Schattendasein.

Abbildung 2: Die Älteren werden sich ans Fidonet erinnern, ein BBS aus den 80er Jahren. Die Webseite knüpft stilistisch daran an.

Mit dem dauerhafte Verlässlichkeit symbolisierenden Namen trat 2012 dann ein neuer Player auf den Markt, die Fido Alliance (Abbildung 3, [4]): Der Name ist ein Akronym für Fast Identity Online, also die “schnelle Identität im Netz” (siehe Kasten “Die Fido-Allianz”).

Fidosophie

Ziel der Fido-Allianz ist es laut Webseite, transaktionssichere, starke Authentifizierung mit guter Usability zu kombinieren und so zugleich Betrügereien vorzubeugen und dem Anbieter einen möglichst effizienten und einheitlichen Authentifizierungsmechanismus an die Hand zu geben.

Der Ansatz will dafür Biometrie und Two-Factor-Authentifizierung zusammenbringen. Das gelingt, indem der Benutzer auf einem Server einen Schlüssel hinterlegt und folgende Anfragen dann über einen lokalen Challenge-Response-Mechanismus bestätigt. Dazu drückt er etwa einen Knopf oder liefert andere Nachweise der physischen Präsenz (etwa über einen Fingerabdruckleser), um einen Dienst freizuschalten. Google habe die Authentifizierung laut Fido-Webseite als eine der ersten Firmen erfolgreich mit Tokens eingesetzt.

Im Gegensatz zu klassischen Authentifizierungsverfahren verzichten Zwei-Faktor-Verfahren wie die von Yubico entwickelten auf einen zentralen Server. Es war ein dringendes Anliegen des Firmen-CTO Jakob Ehrensvard, einen dezentralen Authentifizierungsmechanismus zu entwickeln, der ohne Shared Secrets auskommt, welche die Kommunikationspartner hüten müssten. Zugleich sollte er es aber ermöglichen, beliebige Dienste zu nutzen und dabei die Anonymität der Anwender sicherstellen – also jedem Anwender beliebig viele Identitäten ermöglichen.

Abbildung 3: Die gemeinnützige Fido-Allianz will eine passwortlose Authentifizierung ermöglichen und hat zahlreiche Industrievertreter an Bord.

2014 stellte die Fido Alliance gleichzeitig Version 1.0 des UAF- (Universal Authentication Framework) und des U2F-Protokolls (Universal 2nd Factor) fertig. In den Jahren darauf folgten zahlreiche Implementierungen in Clients und Servern. Zugleich sammelte die Alliance neue Mitglieder aus der IT-Security-, Finanz-, Software- oder auch Biometrie-Branche. 2015 folgte das erste Test- und Zertifizierungsprogramm, danach mobile Implementierungen für I-OS und Android, aber auch kontaktlos über Bluetooth und NFC. Microsoft stieg mit Windows 10 ein, der japanische Provider NTT Docomo ermöglichte seinen 65 Millionen Kunden passwortlose Logins.

Fido 2

Im November 2015 reichte die Allianz den Entwurf für Fido 2.0 beim World Wide Web Consortium ein. Nur drei Monate später gab das W3C die Gründung einer Arbeitsgruppe bekannt. Deren Bestreben: Die Standardisierung für starke Authentifizierungsmechanismen von Webbrowsern und Webseiten auf der Basis der Fido-2.0-Web-APIs voranzubringen.

Das Ziel der Web Authentication Working Group sei es, ein Client-seitiges API für Webanwendungen zu schaffen. Gewünscht sei dabei auch, E-Payment durch Biometrie und andere sekundäre Faktoren sicherer und zugleich einfacher zu machen – weil die meisten Smartphones Fingerprintreader und ähnliche Module bereits an Bord haben.

So seien sowohl Benutzerzufriedenheit wie auch Authentizität des Kreditkartenbesitzers besser gewährleistet als zuvor, sagen Fido und die EMVCo LLC. Letztere wacht für die gängigen Kreditkarten über den EMV-Standard und hat unter anderem Master, Visa und American Express als Mitglieder.

Ende 2016 wurde die Fido-Allianz nach eigener Angabe zum größten Ökosystem für Authentifizierungsstandards. Mehr als 200 zertifizierte Lösungen stünden mittlerweile parat, dank Facebook-Integration hätten mehr als drei Milliarden Menschen Zugriff auf sichere Anmeldeverfahren. Im März 2018 konnte das W3C schließlich Version 2 als W3C Candidate Recommendation vorstellen [7].

Abbildung 4: Auf dem Client-Gerät benutzt die CTAP-Library eine Authentifizierungsmethode, während Webauthn dem Browser dazu dient, die sichere Kommunikation mit einer Web-Applikation oder -Plattform zu gewährleisten. Der Benutzer wählt im Idealfall einfach eine vorher eingerichtete Authentifizierungsmethode. © https://fidoalliance.org

Damit kommen zu den Fido-Klassikern UAF und U2F jetzt in Fido 2 das Client to Authenticator Protocol (CTAP) und das Webauthn-Protokoll als Spezifikation für den Einbau in Browser und Webapplikationen [8]. CTAP kümmert sich auf dem Client um die (eventuell externen) Geräte zur Authentifizierung, während Webauthn die Daten oder Keys von CTAP übernimmt (Abbildung 4).

Funktionsweise

Für den Anwender soll all das einfach und transparent funktionieren. Abbildung 5 zeigt die beiden Varianten mit einem biometrischen Merkmal auf einem Smartphone oder dem Einsatz von USB-Token, Smartcards, Embedded Secure Elements (ESE) oder von TPM-Modulen als Local Device Auth (LDA). Im Hintergrund kommen bei dem neuen Standard Public-Key-Kryptoverfahren zum Einsatz, die das Verfahren in Kombination mit den lokalen 2FA-Mechanismen ebenfalls gut gegen jede Art von Phishing zu rüsten scheinen.

Abbildung 5: Authentifizierungen sollen künftig ganz einfach werden, das verspricht die Fido-Allianz den Benutzern. © https://fidoalliance.org

Im einfachsten Fall registriert sich das Clientgerät mit einem öffentlichen Schlüssel beim Server. Fortan kann die Local Device Auth den privaten Schlüssel freischalten, um die gewünschten Authentifizierungen vorzunehmen.

In der Regel wird der Server den Benutzer dazu auffordern, ein für beide Seiten geeignetes Authentifizierungsverfahren und -gerät auszuwählen. In der Folge erzeugt die Client-Library das spezielle Schlüsselpaar für diese Kombination aus lokalem Device, Onlinedienst und Benutzeraccount. Auf dem Server landet dann der Public Key, ebenfalls verknüpft mit dem Benutzeraccount. Der Server erhält dabei keine Informationen über die lokalen Verknüpfungen beim Kunden, ein Einbrecher könnte also nicht herausfinden, welche Authentifizierungsart der Kunde gewählt hat.

Im Detail läuft der Anmeldeprozess wie folgt ab: Der Server sendet dem Benutzer eine Challenge, damit sich dieser wie vorher einloggt (also auf dem Gerät und mit dem Verfahren, das das Lesen der Keys ermöglicht). Gelingt das dem Client, signiert er die Challenge mit seinem privaten Key und schickt das Ganze an den Server. Der braucht dann nur zu prüfen, ob der Public Key zur Signatur passt, und meldet den Nutzer dann an. Alternativ stößt er einen angeforderten Vorgang an. Der Nutzer kann auf geeigneten Medien auch mehrere Keys speichern, die er je nach Bedarf einsetzt.

Am Beispiel Firefox

Bereits seit Anfang 2018 beherrschen Entwicklerversionen von Firefox das Verfahren, ab Firefox 60 ist die Technologie fest integriert. Auch für die Browser Chrome (Google) und Edge (Microsoft) sehen die Entwickler den künftigen Support für Webauthn vor [9].

Die Listings 1 und 2 zeigen Javascript-Beispiele aus einem Blogbeitrag der Mozilla-Entwickler J. C. Jones und Tim Taubert [10], die ein USB-U2F-Token initialisieren und Public Keys auf dem Client anfordern. Mehr braucht es nicht, den Rest erledigt die lokale Hardware, beispielsweise das USB-Token oder ein Fingerabdruckleser.

01 const cose_alg_ECDSA_w_SHA256 = -7;
02
03 /* The challenge must be produced by the server */
04 let challenge = new Uint8Array([21,31,105,[...]]); /* 29 more random bytes generated by the server */
05
06 let pubKeyCredParams = [{
07   type: "public-key",
08   alg: cose_alg_ECDSA_w_SHA256
09 }];
10
11 let rp = {
12   name: "Test Website"
13 };
14
15 let user = {
16   name: "Firefox User <firefox@example.com>",
17   displayName: "Firefox User",
18   id: new TextEncoder("utf-8").encode("firefox@example.com")
19 };
20
21 let publicKey = {challenge, pubKeyCredParams, rp, user};
22 navigator.credentials.create({publicKey})
23   .then(decodeCredential);

Der Code aus Listing 1 (die beiden Funktionen »navigator.credentials.create()« und »decodeCredential()«) fordert ein neues Fido-Credential an, indem er alle kompatiblen Geräte aktiviert und auf Benutzereingaben warten lässt. Das Credential entsteht, sobald sich der User erfolgreich authentifiziert hat. Die Funktion »decodeCredential()« erzeugt daraus ein Schlüsselpaar und überträgt den öffentlichen Schlüssel (im Klartext).

01   /* The challenge must be produced by the server */
02 let challenge = new Uint8Array([42,42,33,[...]]); /* 29 more random bytes generated by the server */
03
04 let key = new Uint8Array([?]); */ Retrieve Key Handle
05
06 let allowCredentials = [{
07   type: "public-key",
08   id: key,
09   transports: ["usb"]
10 }];
11
12 let publicKey = {challenge, allowCredentials};
13
14 navigator.credentials.get({publicKey})
15   .then(decodeAssertion);

In die Erzeugung des Schlüssels gehen unter anderem die aufgerufene URL und ein Timestamp ein und verknüpfen so diesen Benutzer, diese Webseite und die Authentifizierung miteinander.

Listing 2 zeigt den Prozess für ein bereits existierendes Credential, wenn der Benutzer also die Webseite erneut besucht.

Für Entwickler

Unter [11] bietet die Fido-Alliance selbst Ressourcen für Entwickler an. Die Webseite erweist sich als guter Ausgangspunkt mit direkten Links zur Spezifikation und zu Erläuterungen für die involvierten Protokolle, Plattformen und Funktionen, beispielsweise die oben demonstrierten »navigator.credentials.get()«- und »navigator.credentials.create()«.

Unter Android wickelt »org.fidoalliance.intent.Fido-Operation« alle Funktionen ab – siehe Kapitel 6 der W3C-Spezifikation beziehungsweise Kapitel 7 für I-OS. Diesen Intent hat das Android-Client-API definiert, es bringt alle Funktionen für Login, Registrierung und Änderungen mit. Googles Entwicklerressourcen [12] erweisen sich im Webauthn-Fall als ebenso hilfreich wie die von Github, wo mehr und mehr Projekte die Funktionen implementieren, etwa in Python und mit Yubikeys [13].

Überhaupt: Für einen schnellen Anfang erscheinen Yubico-Token als gute Wahl. Sowohl der Yubikey Neo als auch Fips unterstützen Fido und sind NIST-zertifiziert für den Einsatz in sicherheitskritischen Umgebungen.

Serverseits

Was jetzt noch fehlt, ist die Server-Seite. Hier verweist die Fido-Allianz auf die große Zahl an Servern, die Fido unterstützen. Jeder davon bietet sein eigenes Konfigurationsverfahren an. Die Allianz bietet aber an, die Server als Fido Certified zu zertifizieren [14].

SSL ist eine Grundvoraussetzung, aber ohne eine Datenbank – oder ein LDAP-Benutzerverzeichnis – geht auch erst mal nichts. Yubico listet unter [15] die für eine LDAP-Integration nötigen Schritte auf. Für das Client-to-Authenticator-Protokoll findet sich ein Startpunkt im LDAP-Wiki [16]. Ein noch recht junges Projekt wartet als Fido-2-Server auf Github [17].

Hardware

Schließlich gibt es noch die Partner der Fido Alliance wie Strongkey (vormals Strongauth, [18]). Die Firma bewirbt ihre Enterprise Solution Key Appliance mit einer hohen Datensicherheit (Abbildung 6). Für 3000 US-Dollar gibt es den Fido Fast Start, der den NIST-Anforderungen genügt und “speziell für Regierungsorganisationen entworfen” ist. Bei allem Marketing- und Buzzword-Bingo sieht die Liste der Features der Strongkey-Geräte gut aus.

Abbildung 6: Die Strongkey-Appliance integriert Fido 2. © strongkey.com

Zunächst den Fast Start zu testen scheint der günstigste Einstieg zu sein: Dafür entwickelte Webapps müssen Chrome 50 oder neuer unterstützen, dürfen kein Captcha oder OTP verwenden und müssen sich auf eine URL beschränken – das Nachladen externer Ressourcen ist verboten. Das sollte auch problemlos mit einem Yubikey-Token, Smartphone oder Laptop klappen, die Biometriegeräte enthalten.

Kritik

Fido 2 scheint eine gute Kombination aus Benutzerfreundlichkeit, Sicherheit und Standardisierung zu sein. Unterstützt durch große Konzerne und Organisationen, etwa aus der Kreditkartenbranche, könnte sich der Standard schnell verbreiten – zumal es fertig konfektionierte, günstige Hardware-Appliances gibt.

Auch die Open-Source-Gemeinden um Mozilla, Google (Chrome und Android) und die Communities von Apple und Microsoft haben ihre Hausaufgaben gemacht und treiben den Standard voran. Besonders für Unternehmen scheint die Kombination aus Biometrie – bei allen systemimmanenten technologischen Schwächen – und Token attraktiv, besonders beim anhaltenden Trend zu Webdiensten und Cloud-Apps.

Treibender Faktor dürfte jedoch die Finanzwirtschaft sein. Vermutlich stehen schon bald viele Banking- und Kreditkartenfunktionen auch per Webauthn parat.

Schwächen

Da die Authentifizierung in Fido 2 und Webauthn über den Browser geschieht, dürften Angriffe auf diesen weiter im Fokus stehen. Webauthn ist laut Fido-Allianz aber gegen MITM- und Phishing-Angriffe geschützt.

Erwartbare Probleme verstecken sich zudem beim Einsatz von Biometrie und Credential-Recovery: Biometrische Merkmale als Passwortersatz einsetzen ist riskant. Irisscan, Fingerabdruck oder Tastatur- und Tippverhalten sollten nur als Benutzername dienen, nicht als Passwort. Ist ein Fingerabdruck kompromittiert, bleiben dem Nutzer nur neun andere. Auch hinterlässt er das Merkmal im Alltag überall, präsentiert seine Iris jeder HD-Kamera und sein Tippverhalten jedem Webdienst.

Abseits dieser grundlegenden Bedenken erscheint Biometrie hier jedoch sinnvoll eingesetzt. Der Fingerabdruck gibt ja nur im Rahmen der Präsenzanzeige die Berechtigung, den Key zu erzeugen.

Das Problem gängiger Passwortverfahren (“Kann ich dem Server trauen?”) lässt sich nur durch individuelle Passwörter pro Dienst mindern. Immerhin hilft das Webauthn-Verfahren hier ein gutes Stück – ganz ohne Passwortmanager. Doch es macht dabei die Credential-Speicher zum Single-Point-of-Failure, die Ziel von Angriffen werden dürften.

Das Computer-unabhängige analoge Speichern langer, kryptischer und pro Dienst erzeugter Passwörter ist häufig noch sicherer. Aber wer will das heute in Kauf nehmen? Der Ansatz von Webauthn geht daher in die richtige Richtung: Mehr Sicherheit bei angemessener Usability. Doch er hat auch Schwächen.

Token verloren?

Ein systemimmanentes Problem verursacht der Verlust eines Token. Er wirft die Frage auf, welche Recovery-Funktionen der Onlineshop anbietet. Schon vor Webauthn mahnte Krypto-Papst Bruce Schneier [19]: Jeder Dienst, der Sicherheitsfragen implementiert – etwa zum Passwort-Reset nach dem Geburtsnamen der Mutter fragt –, kann auch auf Passwortregeln verzichten.

Bei Webauthn scheint nur ein neuer Account – das Anlegen eines neuen Credential mit einem neuen Token – die Lösung zu sein. Wie die Betreiber das in der Praxis umsetzen, werden wohl erst Implementierungen auf Banken- und Kreditkartenseiten zeigen. Dort trennt sich heute die Spreu vom Weizen, was etwa die Vorgaben für Passwörter oder die Onlinebanking-Verfahren betrifft.

Im Vergleich zum populären, aber schon lange als verwundbar bekannten SMS-TAN-Verfahren [20] ist Fido 2 allerdings eine große Errungenschaft mit viel Potenzial. Den Einsatz von Passwörtern, TANs und kryptographischen Schlüsseln dürfte der neue Standard Webnutzern aber auch nicht komplett ersparen.