Webauthn: Identitätsdiebstahl ade!
Smartphone & Biometrie – ein neuer Standard für das WWW
Identitätsdiebstahl und Phishing bedrohen weiterhin das World-Wide-Web (WWW). Mit "Web Authentication: An API for accessing Public Key Credentials Level 1" (kurz: Webauthn) [1] haben das World Wide Web Consortium (W3C) und die Fast IDentity Online-Alliance (FIDO) zum 4. März 2019 einen offenen Standard geschaffen, der sichere Anmeldeverfahren im WWW ermöglicht.
Ein besonderer Schwerpunkt liegt auf Usable-Security, d. h. sicherer Benutzerbarkeit und User-Experience (UX): Relevante Use-Cases für End-User sind vorab beschrieben und bilden die Grundlage des Standards.
Zentrale Bestandteile sind außerdem die datenschutzkonforme Einbindung biometrischer Systeme und die Nutzung mobiler Endgeräte (Safetynet Attestation API [2], Key and ID Attestation [3]). Fingerprint-Sensoren können einfach zur Anmeldung im WWW verwendet werden – komplett ohne serverseitige Speicherung biometrischer Daten. Grundlage hierfür bilden kryptographische Verfahren: Durch die Koppelung der Identität (Keypair) an definierte Domains, wird das Abfangen im Rahmen der Anmeldung (Phishing) unterbunden. Identitätsdiebstahl wird signifikant erschwert: Brute-force- und Dictionary-Angriffe – auch auf Server Dritter – werden stark eingeschränkt. Dadurch präsentiert sich Webauthn als WWW-Pendant zu Public-Key-Verfahren wie beispielsweise aus SSH.
In Form eines client-seitigen JavaScript-API erlaubt Webauthn die Einbettung in moderne, JavaScript-basierte Frontends und Apps. Es kann wahlweise im Rahmen einer Ein- oder Mehrfaktor-Authentisierung genutzt werden.
Dieser Artikel beschreibt Hintergrund, Funktionsweise und Nutzung von Webauthn. Dabei wird auf existierende Verfahren zur Multi-Faktor-Authentisierung, die Entwicklung des Standards, Kritik und die Integration in existierende Systemlandschaften eingegangen.
Authentisierung im WWW
Traditionell erfolgt eine Anmeldung mit Benutzername und Kennwort. Diese Form der Anmeldung ist offensichtlich am weitesten verbreitet und wird von nahezu allen Benutzerinnen und Benutzern im WWW akzeptiert – trotz kontrovers diskutierter Usability.
Hierbei entwickeln Nutzerinnen und Nutzer ein intuitiv-transparentes Verständnis für ihre scheinbare Sicherheit: So lange das Kennwort einem Angreifer nicht bekannt ist, ist auch kein Zugriff auf das eigene Konto möglich. Die enorme Anzahl kompromittierter Accounts zeigt jedoch die konzeptionellen Probleme eindrucksvoll auf [4]. Häufig verwenden Nutzerinnen und Nutzer gleiche Zugangsdaten für verschiedene Webdienste. Somit gefährdet ein kompromittierter Account nicht nur den direkt betroffenen Dienst, sondern auch andere: Kriminelle versuchen massenhaft automatisierte Anmeldungen mit gestohlenen Zugangsdaten an anderen Systemen.
Mit einer Multi-Faktor-Authentisierung erhält man zusätzliche Sicherheit: Beispielsweise wird neben einem Kennwort auch ein Hardware-Token (Besitz) oder ein Fingerabdruck (Biometrie) zur Anmeldung benötigt. Übliche Verfahren basieren auf Codes, die entweder einmalig oder nur für kurze Zeit zur Anmeldung verwendet werden.
"Eine sichere Lösung stellt hierbei eine Multifaktor-Authentisierung dar. Dabei sind mindestens zwei Faktoren für eine erfolgreiche Authentisierung erforderlich." (BSI IT-Grundschutz: M 4.441 Multifaktor-Authentisierung für den Cloud-Benutzerzugriff [5]).
Beispiel: One-Time-Password (OTP)
Ein einmalig gültiger Code wird einer TAN-Liste entnommen (Abb. 1), per SMS oder E-Mail (Abb. 2) zugesendet. Optional kann eine Challange (z. B. Position / Index in einer iTan-Liste) verwendet werden.
Beispiel: Time-based One-time Password (TOTP)
Ein temporär gültiger Code wird auf einem speziellen Gerät (Abb. 3, RSA Token) oder nach dem Scan eines QR-Codes auf dem Smartphone (Abb. 4, Google Authenticator) angezeigt.
Einige Verfahren haben jedoch entscheidende Nachteile: Unsichere Kommunikationswege (z. B. SMS) erlauben das Abfangen entsprechender Codes oder haben teilweise lange Zustellzeiten (SMS, E-Mail). Für Benutzerinnen und Benutzer sind zusätzliche Geräte (z. B. Smartphone, Token, ChipTan-Lesegerät) mit Anschaffungskosten oder aufwändigerem Handling verbunden. Dies führt schnell zu einer inakzeptabel schlechten Usability – beispielsweise beim Mobile Shopping.
Viele übliche Verfahren bieten zudem keinen Schutz vor Phishing-Attacken: Sie können nicht verhindern, dass Benutzer den OTP-Code auf einer betrügerischen Internetseite eingeben. Auf diese Weise können Angreifer sowohl Kennwort als auch OTP-Code abfangen und missbrauchen. Andere Verfahren wie TLS-Clientzertifikate schützen zwar vor Phishing-Angriffen, sind jedoch aufgrund ihrer schlechten Usability kaum verbreitet.
Identity Provider (z. B. Google) vereinfachen die Anmeldung signifikant und versprechen bessere Kontrolle. Sie erlauben ihren Kunden, Accounts zur Anmeldung bei Dritten zu verwenden. Ist beispielsweise ein Google-Account mit einem Android-Smartphone verbunden, so muss der Nutzer zur Registrierung der Datenweitergabe lediglich zustimmen (s. Abb. 6). Diese Form der Anmeldung ist weitaus komfortabler, da Benutzer keine weiteren Accounts erstellen oder Kennwörter eingeben müssen und Seitenbetreiber bereits verifizierte Kontaktdaten erhalten. Wird ein Account kompromittiert und verwendet, so erhält der Nutzer einen Hinweis auf ein neues, unbekanntes Gerät. Zentral gesteuert können kompromittierte Accounts deaktiviert oder bereinigt werden. Bei diesem Verfahren funktioniert das Smartphone als Anmelde-Faktor (Besitz); die Kopplung zwischen Identität und Smartphone wird durch verschiedene Merkmale (Kennwort, App oder SMS) abgesichert.
Kurz: Die Anmeldung via Benutzername & Kennwort ist unsicher. Übliche Verfahren zur Multi-Faktor-Authentisierung sind anfällig gegenüber Phishing und bewirken häufig eine inakzeptable schlechte User Experience. Die Speicherung und Weitergabe der Daten durch Identity Provider ist problematisch und bei internen Unternehmensanwendungen ausgeschlossen.
Der Weg zu Webauthn
Die Arbeit an Webauthn begann mit dem "First Public Working Draft" am 31. Mai 2016 im Rahmen des FIDO2-Projekts und wurde knapp drei Jahre später zum 4. März 2019 abgeschlossen. Am Standardisierungsprozess waren Google, Microsoft, Mozilla, Nok Nok Labs, Paypal und Yubico beteiligt.
Vorlage sind Universal 2nd Factor (U2F) und Universal Authentication Frameworks (UAF)-Standards seitens der FIDO Alliance. Beide Standards beschreiben die Verwendung verschiedener Tokens zur Authentisierung. Sie wurden Ende 2014 veröffentlicht und 2017 letztmalig aktualisiert. Ein Teil davon ist das Client to Authenticator Protocol (CTAP), das die Kommunikation zwischen Token und Client spezifiziert: Aufbauend auf dem HID-Protokoll können Tokens wie normale PC-Tastaturen ohne zusätzliche Software verwendet werden.
Das FIDO2-Projekt entstand als Kooperation zwischen der FIDO-Alliance und dem W3C im Herbst 2015. Ergebnisse sind:
- CTAP 2.0 – eine Erweiterung des CTAP-Protokolls und
- Webauthn – eine Erweiterung der JavaScript Credential Management API um Public Keys.
Zentrale Erweiterungen für Endnutzer sind:
- Aufnahme biometrischer Verfahren und
- Authentisierung eines bestimmten Benutzers (z. B. Nutzer mit einem bestimmten Fingerabdruck) anstelle einer Präsenz eines beliebigen Nutzers.
Die Erweiterungen sind dabei abwärtskompatibel: Ältere U2F-Tokens können zusammen mit Webauthn verwendet werden. Weiterhin kann ein Token sowohl CTAP1/U2F als auch CTAP2 parallel unterstützten.
Webauthn aus Benutzersicht
In Webauthn können verschiedene Authenticators verwendet werden. Zum Beispiel: Fingerprint-Reader, NFC-, BLE- oder USB-Token. Es wird zwischen Software- und Hardware-Authenticators unterschieden.
Zunächst wird der Authenticator einmalig registriert – danach ist ein Login beliebig oft möglich. Abb. 8 zeigt die Registrierung und Verwendung des Fingerprint-Readers unter Android. In diesem Beispiel wird der Fingerabdruck als einziger Faktor zum Login genutzt; ein Kennwort ist nicht erforderlich. Die Darstellung richtet sich dabei nach der Plattform.
Abb. 9 und 10 zeigen die Registrierung eines Authenticators unter Windows 10 / Edge und den Login. Der Benutzer hat die Wahl zwischen verschiedenen Verfahren.
Dabei kann Webauthn neben einem Kennwort oder als alleiniger Faktor zur Anmeldung verwendet werden. Beispiele:
- Online-Shop: Die mobile Nutzung soll vereinfacht werden. Benutzer können den Fingerabdruck alternativ zu einem Kennwort nutzen.
- Administrator-Zugang zu einer Cloud-Plattform: Zusätzlich zu einem Kennwort ist ein Webauthn-Authenticator zur Anmeldung erforderlich.
Bei der Registrierung generiert der Authenticator ein individuelles Keypair mit public und private Key und speichert es intern. Backup und Recovery sind damit nicht ohne weiteres möglich. Bei Verlust des Keypairs – beispielsweise durch Verlust oder Beschädigung des Authenticators – kann es nicht mehr zum Login genutzt werden. Mögliche Strategien zur Recovery:
- Neue Authenticators können nach Eingabe eines Kennworts registriert werden. Nutzt ein Online-Shopping-Kunde ein neues Smartphone, so kann er den Fingerabdruck-Scanner mit Eingabe seines Kennworts freischalten.
- Bei Verlust wird ein neuer, bereits registrierter Hardware-Token per Post versendet.
Je nach Threat-Model kann z. B. zusätzlich eine Bestätigung per E-Mail oder Briefpost integriert werden. Weiterhin können Hardware-Authenticator als Master-Token genutzt werden: Zur Registrierung eines weiteren Authenticators wird ein Master-Token benötigt, das sicher verwahrt wird.
Funktionsweise von Webauthn
An der Webauthn-Kommunikation sind Server, JavaScript-Client (Web App) und Authenticator beteiligt. Abb. 11 zeigt die Kommunikation vereinfacht aus der Vogelperspektive.
Bei der Registrierung eines Authenticators erzeugt der Server zunächst eine Challenge und sendet sie samt Login-Daten zum JavaScript-Client im Browser des Nutzers (Web App). Über die Credential-API weist die Web-App das Endgerät an, einen neuen Authenticator zu registrieren. Der Benutzer wählt den Authenticator aus, der daraufhin ein Keypair erstellt und speichert. Als Schutz vor Phishing übermittelt der Browser zusätzlich die Domain an den Authenticator und die Registrierung wird entsprechend eingeschränkt. Zur Verifikation der Domain sollte TLS verwendet werden. Zuletzt werden Credential-ID, Public Key und die Signatur der Challenge an den Server übermittelt, der die Informationen verifiziert und in einer Datenbank hinterlegt.
Zum Login übermittelt der Server erneut eine Challenge. Sie wird vom Browser zusammen mit der Domain an den Authenticator weitergereicht. Nach der Bestätigung durch den Benutzer wird die digitale Signatur zurück an den Server gesendet.
Webauthn-Authenticators unterschreiben ausschließlich Challenges mit digitalen Signaturen. Auch bei Fingerabdruck-Scannern werden keine biometrischen Daten serverseitig gespeichert: Ein korrekter Fingerabdruck weist den Authenticator lediglich an, eine kryptographische Signatur zu übermitteln.
Integration in Web-Anwendungen
Soll Webauthn alleinstehend oder als weiterer Faktor in einer Webanwendung genutzt werden, so sind Anpassungen am Server und JavaScript-Client notwendig. Beispielsweise dürfen ein JSON-Web-Token (JWT) oder eine gültige Session erst nach Übermittlung der signierten Challenge erstellt werden. In der Regel werden verfügbare Commercial-off-the-shelf-Authenticators verwendet. Nutzbare Geräte können durch Merkmale serverseitig eingeschränkt werden. Beispielsweise listet der FIDO Metadataservice [6] unsichere Authenticators, die ausgeschlossen werden sollten. Authenticator, Plattform und Browser implementieren CTAP bereits out-of-the-box.
Der Server benötigt dabei Service-Endpunkte zum Erstellen und Validieren der Challenges. Client-seitig müssen die Endpunkte in den Workflow eingebunden und via Ajax aufgerufen werden. WebAuthn.io [7] listet verschiedene OpenSource Libraries zur Integration in verschiedenen Programmiersprachen. In Googles WebAuthn Demo [8] läuft die Kommunikation zwischen Server und Client wie folgt ab, die JSON-Struktur entspricht etwa den Objekten der Webauthn-API im Browser:
Der Client fordert zunächst eine Challenge an. Der Server übermittelt daraufhin Challenge und Merkmale (u. a. nutzbare kryptographische Algorithmen):
{
"rp": {
"id": "webauthndemo.appspot.com",
"name": "webauthn-demo"
},
"user": {
"name": "jan.luehr@anderscore.com",
"displayName": "jan.luehr@anderscore.com",
"id": "amFuLmx1ZWhyQGFuZGVyc2NvcmUuY29t"
},
"challenge": "q48avDE6SocaXmR5Hoo2+mZPN1o18ehIVVoDVs179rk=",
"pubKeyCredParams": [
{ "type": "public-key", "alg": -7 },
{ "type": "public-key", "alg": -35 },
{ "type": "public-key", "alg": -36 },
{ "type": "public-key", "alg": -257 },
{ "type": "public-key", "alg": -258 },
{ "type": "public-key", "alg": -259 },
{ "type": "public-key", "alg": -37 },
{ "type": "public-key", "alg": -38 },
{ "type": "public-key", "alg": -39 }
],
"authenticatorSelection": {
"requireResidentKey": false
},
"session": {
"id": 4652755411009536,
"challenge": "q48avDE6SocaXmR5Hoo2+mZPN1o18ehIVVoDVs179rk=",
"origin": "webauthndemo.appspot.com"
}
}Der Client fordert eine Signatur beim Authenticator an und übermittelt sie an den Server.
{
"id": "SWLmKeDUHzwvzVePwOcVTgVaFMuxeWVuMvdCFV1BYo2DfxE8QVxZAh7oegiLs4iSU0Mwj36LnJnBws0jZNm5Zg",
"type": "public-key",
"rawId": "SWLmKeDUHzwvzVePwOcVTgVaFMuxeWVuMvdCFV1BYo2DfxE8QVxZAh7oegiLs4iSU0Mwj36LnJnBws0jZNm5Zg==",
"response": {
"clientDataJSON": "eyJjaGFsbGVuZ2UiOiJxNDhhdkRFNlNvY2FYbVI1SG9vMi1tWlBOMW8xOGVoSVZWb0RWczE3OXJrIiwib3JpZ2luIjoiaHR0cHM6Ly93ZWJhdXRobmRlbW8uYXBwc3BvdC5jb20iLCJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIn0=",
"attestationObject": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YVjERsx/uWedVbLbkJLhyNnl4dArdYDwtIEsdwli4eSPWthBAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEli5ing1B88L81Xj8DnFU4FWhTLsXllbjL3QhVdQWKNg38RPEFcWQIe6HoIi7OIklNDMI9+i5yZwcLNI2TZuWalAQIDJiABIVggZnMNmdBKmz6J1e1dxbRR6/veqmuN53wwkumCZ8WUHxMiWCBLBfnZbEMk/9lcV+SGBz/RRj1/PbJpngITBdilmokYGQ=="
}
}Die Anmeldung erfolgt analog. Zunächst fordert der Client erneut eine Challenge an und erhält:
{
"challenge": "LFUckFx03SfWCyvo9nbnWnYWElaH3i/HeoeWiAA3o0s=",
"rpId": "webauthndemo.appspot.com",
"allowCredentials": [
{
"type": "public-key",
"id": "SWLmKeDUHzwvzVePwOcVTgVaFMuxeWVuMvdCFV1BYo2DfxE8QVxZAh7oegiLs4iSU0Mwj36LnJnBws0jZNm5Zg=="
}
],
"session": {
"id": 4925566901813248,
"challenge": "LFUckFx03SfWCyvo9nbnWnYWElaH3i/HeoeWiAA3o0s=",
"origin": "webauthndemo.appspot.com"
}
}In der folgenden Nachricht übermittelt der Client die passende Signatur. Da ein alter U2F-Authenticator genutzt wird, ist das Feld userHandle nicht gefüllt.
{
"id": "SWLmKeDUHzwvzVePwOcVTgVaFMuxeWVuMvdCFV1BYo2DfxE8QVxZAh7oegiLs4iSU0Mwj36LnJnBws0jZNm5Zg",
"type": "public-key",
"rawId": "SWLmKeDUHzwvzVePwOcVTgVaFMuxeWVuMvdCFV1BYo2DfxE8QVxZAh7oegiLs4iSU0Mwj36LnJnBws0jZNm5Zg==",
"response": {
"clientDataJSON": "eyJjaGFsbGVuZ2UiOiJMRlVja0Z4MDNTZldDeXZvOW5iblduWVdFbGFIM2lfSGVvZVdpQUEzbzBzIiwib3JpZ2luIjoiaHR0cHM6Ly93ZWJhdXRobmRlbW8uYXBwc3BvdC5jb20iLCJ0eXBlIjoid2ViYXV0aG4uZ2V0In0=",
"authenticatorData": "Rsx/uWedVbLbkJLhyNnl4dArdYDwtIEsdwli4eSPWtgBAAAACQ==",
"signature": "MEUCICX02I7mAR2XxtBRya679AwfCPVPeRDRpl6FInRb3L0KAiEAtT/d2GY8qWVbCFXL6mqsYa/iXpYtKKnF48oRzgbMaO4=",
"userHandle": ""
}
}Clientseitig werden die Nachrichten wie folgt verarbeitet (auf Grund der Länge des Codes sind die Listings auf Github verlinkt):
Zur Registrierung eines Authenticators erstellt der Client neue Credentials (navigator.credentials.create(..). Dabei übergibt er die erhaltene Nachricht an die Webauthn-API und sendet über ein Promise die Signatur an den Server.
Beim Login wird die Signatur hingegen von navigator.credentials.get(..) erstellt.
Serverseitig werden für die Erstellung und Validierung verschiedene Java-Servlets verwendet. Sie behandeln jeweils einen Request.
Erstellung der Credentials:
- Registrierung des Authenticators: BeginMakeCredential
- Login: BeginGetAssertion
Validierung der Signatur:
- Registrierung des Authenticators: FinishMakeCredential
- Login: FinishGetAssertion
Kritik an Webauhtn
Am 23. August 2018 veröffentlichte die Paragon Initiative eine Analyse von Webauthn. Im Blog-Eintrag "Security Concerns Surrounding WebAuthn: Don't Implement ECDAA (Yet)" [9] bewertet die Firma die Sicherheit des seinerzeit aktuellen Entwurfs zu Webauthn. Hierbei ziehen die Autoren ein positives Gesamtfazit. Sie bestätigen, dass Webauthn einen deutlich besseren Schutz bietet als andere – zum Beispiel TOTP-basierte – Verfahren. Insbesondere sei der Schutz vor Phishing relevant. In SMS sehen sie ein "Security-Theater", das vermieden werden müsse. Die Autoren entdeckten keine direkt für Angriffe nutzbare Schwachstellen im Standard.
Die Autoren kritisieren jedoch, dass einige genutzte kryptographischen Verfahren gegen etablierte, Best Practices verstießen. Ihre Kritikpunkte sind die Verwendung von:
- RSA und PKCS1 v1.5.
- Nicht-deterministischen Nonces.
- Einem selbstgestrickten Protokoll (ECDAA), basierend auf Barreto-Naehrig Kurven.
- Verzicht auf Point-Compression oder ähnliche Verfahren.
Nach Auffassung der Autoren führe die Verwendung zu einer kryptographischen Schwächung, aus der sich jedoch keine praktischen Angriffe konstruieren ließen. Mit ihrer Kritik wendet sich die Paragon Initiative in erster Line an die Autoren des Standards. Webauthn verfügt jedoch über einen umfangreichen Katalog unterstützter Verfahren: Die FIDO Server Requirements and Transport Binding Profile [10] sehen auch Verfahren ohne RSA / PKCS1 v1.5 vor. Die Verfahren müssen dann vom Authenticator unterstützt werden – häufig unterstützen ältere Tokens keine neueren Verfahren.
Der ebenfalls kritisierte FIDO ECDAA Algorithmus[11] wird optional verwendet, um Authenticators auf Basis anonymer Gruppensignaturen zu verifizieren. Die Kritik der Paragon Initiative ist damit für Authenticator-Hersteller relevant: BLS12-Kurven könnten die genutzten Barreto-Naehrig-Kurven ersetzen. Entsprechende Änderungen seien dann in Hardware-Tokens zu implementieren.
Für Anwendungsentwickler sind die Kritikpunkte eher uninteressant. Nonces und Error-Handling als Alternative zu Point-Compression werden in erster Linie von existierenden Krypto-Bibliotheken übernommen. Mit Yubicos java-webauthn-server [12] steht beispielsweise eine vollständige Bibliothek zur Verfügung, die serverseitig eigebettet werden kann.
Vergleichbar mit TLS können Entwickler, DevOps und Betrieb vom Grundsatz her die Sicherheit durch Auswahl passender Algorithmen beeinflussen.
Fazit
Webauthn ermöglicht eine gute User Experience. Die W3C-Standardisierung basierend auf U2F und UAF erlaubt es, sichere Anmeldeverfahren plattformunabhängig im WWW zu nutzen. Damit positioniert sich Webauthn auch als Alternative zu Identity Providern wie Google.
Datenschutzrechtlich ist Webauthn relativ unbedenklich. Es werden neben der Credential-ID keine zusätzlichen, personenbezogenen Daten übertragen oder serverseitig verarbeitet. Daten wie IP-Adressen oder Benutzer-Logins fallen auch bei anderen Verfahren an. Der Verzicht auf die serverseitige Speicherung biometrischer Daten wirkt durchdacht.
Die Kritik der Paragon an Webauthn ist grundsätzlich berechtigt. Die Auswahl passender Algorithmen erfordert zusätzliches kryptographisches Know-how. In der Konsequenz entstehen eine höhere Komplexität und Fehleranfälligkeit bei der Umsetzung.
Ich selbst sehe in Webauthn eine interessante Option für kundenspezifische Enterprise-Anwendungen: Als offener Standard ist Webauthn sowohl für interne als auf für externe Software relevant.
- Web Authentication: An API for accessing Public Key Credentials
- SafetyNet Attestation API
- Key and ID Attestation
- have i been pwned?
- BSI – IT-Grundschutz: M 4.441 Multifaktor-Authentisierung für den Cloud-Benutzerzugriff
- FIDO Metadataservice
- WebAuthn.io
- Googles WebAuthn Demo
- Blog-Eintrag: Security Concerns Surrounding WebAuthn: Don't Implement ECDAA (Yet)
- Server Requirements and Transport Binding Profile
- FIDO ECDAA Algorithmus
- Yubicos java-webauthn-server
