{"id":2397,"date":"2018-01-25T14:47:17","date_gmt":"2018-01-25T13:47:17","guid":{"rendered":"http:\/\/blog.mozilla.org\/press-de\/?p=2397"},"modified":"2018-01-25T14:47:17","modified_gmt":"2018-01-25T13:47:17","slug":"wie-hardware-token-basierte-zwei-faktor-authentifizierung-mit-der-webauthn-api-funktioniert","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/press-de\/2018\/01\/25\/wie-hardware-token-basierte-zwei-faktor-authentifizierung-mit-der-webauthn-api-funktioniert\/","title":{"rendered":"Wie Hardware-Token-basierte Zwei-Faktor-Authentifizierung mit der WebAuthn-API funktioniert"},"content":{"rendered":"

Um eine h\u00f6here Sicherheit f\u00fcr die Anmeldung zu gew\u00e4hrleisten, setzen Webseiten eine Zwei-Faktor-Authentifizierung (2FA) ein, wobei derzeit h\u00e4ufig eine Smartphone-App oder Textnachrichten verwendet werden. Diese Mechanismen erschweren das Phishing<\/a>, k\u00f6nnen es aber nicht vollst\u00e4ndig verhindern – Benutzer k\u00f6nnen immer noch dazu verleitet werden, Codes weiterzugeben und auch SMS-Nachrichten sind nicht vor Abfangen gesch\u00fctzt.<\/p>\n

Firefox 60 wird mit standardm\u00e4\u00dfig aktivierter WebAuthn-API<\/a> ausgeliefert. Diese bietet eine Zwei-Faktor-Authentifizierung, die auf Public-Key-Kryptographie<\/a> basiert und die gegen Phishing, wie wir es heute kennen, immun ist. In dieser Einf\u00fchrung erfahren Sie, wie Sie Millionen von Nutzern, die bereits im Besitz von FIDO U2F USB-Token<\/a> sind, absichern k\u00f6nnen.<\/p>\n

Registrierung von Zweit-Faktoren<\/b><\/p>\n

Beginnen wir mit einem einfachen Beispiel: Eine Webseite fordert ein neues Credential an, das mit einem standardm\u00e4\u00dfigen, \u00fcber USB angeschlossenen FIDO U2F-Ger\u00e4t kompatibel ist. Es gibt viele dieser kompatiblen Token, die Yubikey, U2F Zero oder auch anders hei\u00dfen:<\/p>\n

const<\/span> cose_alg_ECDSA_w_SHA256 = -7<\/span>;\r\n\r\n\/* Die Challenge wird vom Server generiert. *\/<\/span>\r\nlet<\/span> challenge = new<\/span> Uint8Array<\/span>([21<\/span>,31<\/span>,105<\/span> \/* 29 weitere, vom Server zuf\u00e4llig generierte Bytes *\/<\/span>]);\r\nlet<\/span> pubKeyCredParams = [{\r\n  type<\/span>: \"public-key\"<\/span>,\r\n  alg<\/span>: cose_alg_ECDSA_w_SHA256\r\n}];\r\nlet<\/span> rp = {\r\n  name<\/span>: \"Test Website\"<\/span>\r\n};\r\nlet<\/span> user = {\r\n  name<\/span>: \"Firefox User <firefox@example.com>\"<\/span>,\r\n  displayName<\/span>: \"Firefox User\"<\/span>,\r\n  id<\/span>: new<\/span> TextEncoder(\"utf-8\"<\/span>).encode(\"firefox@example.com\"<\/span>)\r\n};\r\n\r\nlet<\/span> publicKey = {challenge, pubKeyCredParams, rp, user};\r\nnavigator.credentials.create({publicKey})\r\n  .then(decodeCredential);<\/code><\/pre>\n
Werden USB U2F-Token verwendet, warten alle kompatiblen Token, die mit dem System des Nutzers verbunden sind, auf eine Interaktion mit diesem. Sobald der Nutzer eines der Ger\u00e4te ber\u00fchrt, wird ein neues Credential generiert und das Promise<\/i> aufgel\u00f6st.<\/p>\n
Die benutzerdefinierte Funktion\u00a0decodeCredential()<\/code><\/i>dekodiert die Antwort, um eine Schl\u00fcsselkennung zu erhalten. Diese ist entweder eine ID f\u00fcr das auf dem Ger\u00e4t gespeicherte ECDSA-Schl\u00fcsselpaar oder das ECDSA-Schl\u00fcsselpaar selbst, verschl\u00fcsselt mit einem geheimen, ger\u00e4tespezifischen Schl\u00fcssel. Der \u00f6ffentliche Schl\u00fcssel, der zum ECDSA-Paar geh\u00f6rt, wird im Klartext gesendet.<\/p>\n
Die Schl\u00fcsselkennung, der \u00f6ffentliche Schl\u00fcssel und eine Signatur m\u00fcssen vom Backend mittels der zuf\u00e4lligen Challenge<\/em> verifiziert werden. Da ein Credential kryptographisch an die Webseite gebunden ist, die es angefordert hat, w\u00fcrde dieser Schritt fehlschlagen, sollten die urspr\u00fcnglichen Angaben nicht \u00fcbereinstimmen. Dies verhindert die Wiederverwendung von Credentials, die f\u00fcr andere Webseiten generiert wurden.<\/p>\n
Sofern erfolgreich, werden Schl\u00fcsselkennung und \u00f6ffentlicher Schl\u00fcssel fortan dem aktuellen Benutzer zugeordnet. Die WebAuthn-API setzt keine spezifische Browser-Benutzeroberfl\u00e4che voraus, sodass es in der alleinigen Verantwortung der Webseite liegt, den Nutzern zu signalisieren, wann sie sich mit einem Token registrieren sollen.<\/p>\n
Anmeldung mithilfe eines registrierten Zweit-Faktors<\/b><\/p>\n
Wenn sich der Nutzer das n\u00e4chste Mal auf der Webseite anmeldet, muss er den Besitz des zweiten Faktors nachweisen, der die Credentials im vorherigen Abschnitt erstellt hat. Das Backend sendet die gespeicherte Schl\u00fcsselkennung mit einer neuen Challenge<\/i> an den Benutzer. Da\u00a0allowCredentials\u00a0<\/code>ein Array ist, erlaubt es das Senden von mehr als einer Schl\u00fcsselkennung, falls mehrere mit einem Benutzerkonto registriert wurden.<\/p>\n
\/* Die Challenge wird vom Server generiert. *\/<\/span>\r\nlet<\/span> challenge = new<\/span> Uint8Array<\/span>([42<\/span>,42<\/span>,33<\/span> \/* 29 weitere, vom Server zuf\u00e4llig generierte Bytes *\/<\/span>]);\r\nlet<\/span> key = new<\/span> Uint8Array<\/span>(\/* \u2026 die Schl\u00fcsselkennung \u2026  *\/<\/span>);\r\n\r\nlet<\/span> allowCredentials = [{\r\n  type<\/span>: \"public-key\"<\/span>,\r\n  id<\/span>: key,\r\n  transports<\/span>: [\"usb\"<\/span>]\r\n}];\r\n\r\nlet<\/span> publicKey = {challenge, allowCredentials};\r\n\r\nnavigator.credentials.get({publicKey})\r\n  .then(decodeAssertion);<\/code><\/pre>\n
Auch hierbei warten alle angeschlossenen USB U2F-Token auf die Interaktion des Nutzers. Wenn der Nutzer ein Token ber\u00fchrt, wird dieser versuchen, entweder die gespeicherte Schl\u00fcsselkennung mit der angegebenen ID zu finden oder diese mit dem internen, geheimen Schl\u00fcssel zu entschl\u00fcsseln. Ist dies erfolgreich, wird eine Signatur zur\u00fcckgeschickt. Andernfalls wird der Authentifizierungsvorgang abgebrochen und muss von der Webseite wiederholt werden.<\/p>\n
Nach der Dekodierung werden die Signatur und die Schl\u00fcsselkennung, mit der signiert wurde, an das Backend gesendet. Wenn der mit der Schl\u00fcsselkennung gespeicherte \u00f6ffentliche Schl\u00fcssel in der Lage ist, die gegebene Signatur \u00fcber die bereitgestellte Challenge zu verifizieren, wird der Nutzer erfolgreich angemeldet.<\/p>\n
Ein-Faktor-Authentifizierung<\/b><\/p>\n
Web Authentication definiert auch Mechanismen, mit denen man sich ohne Benutzername und Passwort nur mit einem einzelnen, sicheren Token einloggen kann – wie z.B. die vertrauensw\u00fcrdige Ausf\u00fchrungsumgebung auf Ihrem Smartphone. In diesem Modus best\u00e4tigt Ihr Token, dass Sie diesen nicht nur besitzen, sondern auch, dass Sie als Person den Token entsperrt haben und zwar mit einem Passcode (etwas, das Sie kennen) und\/oder mit biometrischen Daten (quasi etwas, das Sie sind).<\/p>\n
Nach vorheriger Anmeldung auf einer Webseite k\u00f6nnte diese Ihnen dann erlauben, eine nahtlose Authentifizierung bei einer Webanwendung auf Ihrem Desktop durchzuf\u00fchren – und zwar ganz einfach, indem Sie auf eine Eingabeaufforderung antworten, die auf Ihrem Smartphone angezeigt wird.<\/p>\n
Die momentan eingesetzten FIDO U2F-Token sind noch nicht ausgereift genug, um dies zu erm\u00f6glichen; die n\u00e4chste Generation von Token allerdings schon, sodass Webentwickler mit diesen FIDO 2.0-Token \u00fcber die Web Authentifizierung interagieren k\u00f6nnen werden.<\/p>\n
WebAuthn – bald in Ihrem Firefox<\/b><\/p>\n
Wir m\u00f6chten Entwickler dazu ermutigen, mit WebAuthn zu experimentieren und es Nutzern zu erm\u00f6glichen, ihre Anmeldungen mit zwei Faktoren abzusichern, sobald die API verf\u00fcgbar ist. Uns sind zum Zeitpunkt der Erstellung noch keine WebAuthn-U2F Polyfill-Bibliotheken bekannt, aber wir hoffen, dass sie bald verf\u00fcgbar sein werden. Sollte Ihnen bereits etwas Vielversprechendes \u00fcber den Weg gelaufen sein, schreiben Sie uns gerne einen Kommentar.<\/p>\n
Standardisierte Zwei-Faktor-Authentifizierung ins Web zu bringen, stellt f\u00fcr uns einen bedeutenden Meilenstein dar. Public-Key-Kryptographie sch\u00fctzt unsere Daten, wenn sie \u00fcber das TLS-Protokoll im Internet unterwegs sind – und jetzt k\u00f6nnen wir damit auch noch das Phishing viel, viel schwerer machen. Probieren Sie WebAuthn doch am besten gleich in Firefox Nightly aus!<\/p>\n
\"\"<\/a>Ein letzter Hinweis zum Testen<\/b><\/p>\n
Die WebAuthn API ist ein leistungsstarkes Feature. Daher kann es nur in einem Secure Context<\/a> verwendet werden und wenn es in einem Frame aufgerufen wird, nur dann, wenn alle Frames vom gleichen Ursprung (Origin<\/i>) wie das \u00fcbergeordnete Dokument stammen. Das bedeutet, dass Sie wahrscheinlich auf Sicherheitsfehler sto\u00dfen werden, wenn Sie auf einigen popul\u00e4ren Test-Websites (wie z.B. jsfiddle.net) damit experimentieren.<\/p>\n","protected":false},"excerpt":{"rendered":"
Um eine h\u00f6here Sicherheit f\u00fcr die Anmeldung zu gew\u00e4hrleisten, setzen Webseiten eine Zwei-Faktor-Authentifizierung (2FA) ein, wobei derzeit h\u00e4ufig eine Smartphone-App oder Textnachrichten verwendet werden. Diese Mechanismen erschweren das Phishing, k\u00f6nnen … Mehr lesen<\/a><\/p>\n","protected":false},"author":495,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[30],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/press-de\/wp-json\/wp\/v2\/posts\/2397"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/press-de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/press-de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/press-de\/wp-json\/wp\/v2\/users\/495"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/press-de\/wp-json\/wp\/v2\/comments?post=2397"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/press-de\/wp-json\/wp\/v2\/posts\/2397\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/press-de\/wp-json\/wp\/v2\/media?parent=2397"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/press-de\/wp-json\/wp\/v2\/categories?post=2397"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/press-de\/wp-json\/wp\/v2\/tags?post=2397"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Dies war eine sehr kurze Einf\u00fchrung in die Welt der Web-Authentifizierung und sie verzichtet bewusst auf spezifische Details wie CBOR-Encoding<\/a> und COSE-Key-Formate<\/a> sowie weitere Parameter, die an die\u00a0.create()<\/code>und .get()<\/code>–<\/i>Funktionen \u00fcbergeben werden k\u00f6nnen.<\/p>\n