Interview mit dem Senior Certification Engineer der FIDO Alliance zur passwortlosen Authentifizierung
Unsere Nutzer haben uns gebeten, die Zwei-Faktor-Authentifizierung über die Google-Anwendung zu implementieren. Und vor kurzem haben wir ihnen diese Gelegenheit gegeben. Etwa zur gleichen Zeit veröffentlichte das FIDO Alliance-Konsortium Standards für die kennwortlose Authentifizierung auf Websites, in mobilen Anwendungen und Webdiensten - WebAuthn und CTAP.
Wir haben uns für dieses Thema interessiert und
Material zu Habré vorbereitet , in dem wir über die Methoden gesprochen haben, die den neuen Protokollen zugrunde liegen.
Um einige Punkte in Bezug auf die Feinheiten des Standards zu klären, haben wir mit Yuri Akkermann (
herrjemand ), Senior Certification Engineer bei der FIDO Alliance, gesprochen. Er beantwortete einige unserer Fragen zur vergangenen, gegenwärtigen und zukünftigen Authentifizierung von FIDO. Wir präsentieren Ihnen den Text des Interviews.
/ Flickr / zhrefch / PDBitte teilen Sie uns Ihren Hintergrund und Ihre Erfahrung im gesamten IT-Bereich mit. Wie haben Sie Ihre Arbeit in der Branche begonnen?
Ich programmiere seit meinem 15. Lebensjahr. Nach der Schule ging ich zur Universität, wo ich Informatik und Mathematik studierte. Im zweiten Jahr interessierte ich mich für Kryptographie, Fragen der Informationssicherheit und stolperte über FIDO. Ihre Protokolle haben mir sehr gut gefallen, und am Ende habe ich eine U2F-Bibliothek für Python Flask geschrieben und eine Präsentation gemacht.
Meine Arbeit wurde von FIDO geschätzt. Außerdem suchten sie nur einen Zertifizierungsingenieur. Am Ende wurde ich für die technische Zertifizierung verantwortlich.
Wie lange beschäftigen Sie sich schon mit Themen im Zusammenhang mit der Authentifizierung bei FIDO? Welche Aufgaben haben Sie bei der Entwicklung eines neuen Standards gelöst?
Ich arbeite seit drei Jahren mit FIDO-Protokollen - zwei davon in der FIDO Alliance. Meine Hauptaufgabe sind technische Zertifizierungen und automatisierte Tools zum Testen von Implementierungen gemäß Spezifikationen. Zu meinen Aufgaben gehören das Entwickeln und Unterstützen der Tools selbst sowie das Schreiben von Testplänen - Testlisten zum Überprüfen von Servern, Clients und Authentifikatoren. Ich denke, dass das Schreiben eines Testplans der zeitaufwändigste Prozess ist, da ein Verständnis aller Feinheiten der Protokolle und der darin verwendeten Standards erforderlich ist.
Ich berate auch Arbeitsgruppen über mögliche Verbesserungen der Spezifikationen, mache Präsentationen und schreibe von Zeit zu Zeit Artikel.
Wie entstand die Idee, einen neuen Standard für die Authentifizierung zu schaffen? Warum haben Sie entschieden, dass die Welt und die Gemeinschaft in diesem Bereich eine neue Lösung brauchen? Was sind die Nachteile bestehender Formate, die WebAuthn schließen soll?
Die FIDO Alliance wurde 2013 von Agnitio, Infineon Technologies, Lenovo, Nok Nok Labs, PayPal und Validity gegründet, die UAF entwickelten. Wenig später kamen Google, Yubico und NXP hinzu - diese arbeiteten am Vorgänger von U2F und hielten es für rentabel, sich zusammenzuschließen, da ihre Ideen mit den Ideen der Allianz übereinstimmten. Sie wollten Internetnutzer vor Phishing schützen, die Usability-Probleme von Passwörtern lösen und die Zugänglichkeit und Sicherheit biometrischer Technologien verbessern.
Wurden Vorstudien durchgeführt, die entweder die Absicht, einen Standard zu schaffen, bekräftigten oder zu dessen Schaffung veranlassten? Wenn ja, welche Art von Daten haben Sie analysiert?
Allianzmitglieder wie Google, Microsoft, Samsung, Yubico und andere arbeiten aktiv daran, Standards zu schaffen und zu fördern. Sie erforschen Märkte und versuchen zu verstehen, wie FIDO in verschiedene Ökosysteme "passen" kann. Google hat beispielsweise
eine Studie zur Migration des zweiten Faktors von Einmalkennwörtern zu U2F durchgeführt.
Wie wurde das CTAP-Protokoll geboren? Wie ist es mit WebAuthn verbunden?
FIDO besteht aus drei Teilen: Server, Client (Browser) und Authentifikator. Der Server sendet einen Anruf an den Client, der Client leitet den Anruf an den Authentifikator weiter, der ihn signiert und an den Client zurücksendet, und dieser wird bereits an den Server gesendet.
Damit der Server die FIDO-Authentifizierung verwenden kann, verfügen die Clients über eine WebAuthn JS-API. Der Client kommuniziert mit Authentifikatoren über das Low-Level-Protokoll CTAP2 (Client-to-Authenticator Protocol 2). CTAP2 beschreibt CBOR-Abfragestrukturen und -transporte wie USB, NFC und BLE für die Kommunikation mit einem Authentifikator. Die Kombination dieser beiden Standards heißt FIDO2.
Eines der Ziele bei der Erstellung des Formats ist der Schutz vor Phishing. Was sind einige der Vorteile gegenüber anderen Lösungen?
Wenn wir über vorhandene Lösungen sprechen, kann FIDO nur mit Client-Zertifikaten oder TLS CCA (Client Certificate Authentication) verglichen werden. FIDO und CCA sind phishing-sichere Anrufantwortprotokolle für öffentliche Schlüssel. Aber sie haben signifikante Unterschiede.
CCA sind nicht vor einem Wiederholungsangriff geschützt. Sie verwenden ein einzelnes Zertifikat an mehreren Standorten wieder, was zur Dekanonymisierung des Benutzers führen kann. Bei FIDO generieren wir für jede Registrierung ein neues eindeutiges Schlüsselpaar, um die Privatsphäre zu schützen.
CCA hat auch ein Problem beim Speichern von Schlüsseln, da der private Schlüssel in den meisten Fällen entweder in PKCS12 verschlüsselt ist oder einfach im Klartext liegt. Somit kann selbst eine nicht privilegierte Anwendung sie problemlos stehlen. In FIDO werden alle Schlüssel sicher aufbewahrt, z. B. im Einweg-SecureEnclave-Speicher. Das Wiederherstellen von Schlüsseln aus dieser Art von Speicher ist sehr schwierig.
CCA hat Schwierigkeiten mit der ordnungsgemäßen Implementierung auf der Serverseite, da eine vollständige CCA-Unterstützung zu wünschen übrig lässt. Aufgrund der Komplexität der Arbeit mit TLS machen Entwickler viele Fehler. FIDO benötigt nur Unterstützung für die grundlegende Kryptographie. CCA kann über HTTP implementiert werden, was in WebAuthn nicht möglich ist. CCA hat auch Probleme mit der Portabilität und der Benutzerfreundlichkeit.
Ich glaube nicht, dass die Allianz etwas Neues erfunden hat. Wir haben einfach ein gutes Protokoll entwickelt, das vorhandene Sicherheitsmechanismen enthält.
/ Flickr / markus spiske / PDWird die Verwendung des Standards keine zusätzlichen Angriffsvektoren ergeben, die mit der Tatsache zusammenhängen, dass eine große Menge biometrischer Informationen gespeichert werden muss?
Eines unserer Grundprinzipien ist die Privatsphäre. Biometrische Informationen werden auf sicheren Chips gespeichert und verlassen diese nie. Unsere Unternehmen arbeiten mit von FIDO oder FIPS zertifizierten Lesern.
Wir verwenden biometrische Informationen auch nur zur Bestätigung der Anwesenheit des Benutzers. Und wir haben ein biometrisches Zertifizierungsprogramm zum Testen von Authentifikatoren.
Sie haben einmal gesagt, dass die Authentifizierung per SMS-Code eine schlechte 2FA-Option ist. Wie können Sie dies kommentieren?
SMS-Codes oder SMS-OTP ist eine Zwei-Faktor-Authentifizierung mit Einmalkennwörtern, die per SMS übermittelt werden. Daher stellt sich heraus, dass diese Lösung anfällig für Phishing ist. Was hindert ihn daran, einen SMS-Code an Cyberkriminelle zu senden, wenn Ihr Benutzer in Phishing verwickelt ist und seinen Benutzernamen und sein Passwort angibt?
Wir sollten die Probleme bei der Verwendung von SMS als Transportmittel nicht vergessen. Vor drei Jahren wurden 400.000 Konten aufgrund einer Sicherheitslücke im SS7-Protokoll, mit dem Telekommunikationsinformationen zwischen verschiedenen Telekommunikationsbetreibern weitergeleitet werden, in eine deutsche Bank gehackt. Angreifer, die unbefugten Zugriff auf das SS7-Netzwerk erhalten haben, in dem keine Authentifizierung erfolgt, konnten die Nummern der Opfer selbst registrieren und ihre Codes abrufen.
Außerdem kann heute jeder eine GSM-Basisstation für 500 bis 600 US-Dollar kaufen und SMS mit einem MITM-Angriff abfangen. Und schließlich sind mit Social Engineering Gefahren verbunden. Ich denke, viele
kennen die Geschichte, als Angreifer einen erheblichen Geldbetrag von Bankkonten gestohlen haben, indem sie ein Duplikat der SIM-Karte des Opfers ausgestellt haben. Dies geschieht in Russland und anderen Ländern mit beneidenswerter Regelmäßigkeit.
Was ist, wenn Sie den Dienst auf mehreren Geräten eingeben müssen oder mehrere Personen denselben Dienst gleichzeitig nutzen? Unterstützt der Standard diese Betriebsart?
Im Gegensatz zu einem Passwort kann es viele Authentifikatoren geben. Der Benutzer kann sein Telefon, seinen Laptop und sein Token registrieren und jedes davon zur Authentifizierung verwenden. Außerdem kann ein Token ohne Verlust der Privatsphäre an mehrere Konten „gebunden“ werden.
Aber was ist, wenn der Token verloren gegangen ist? Wird es möglich sein, den Zugang zu Diensten zurückzugeben?
Die FIDO-Authentifizierung sollte als Home-Schlüssel betrachtet werden. Wenn Sie Ihre Schlüssel verloren haben, können Sie die Ersatzschlüssel jederzeit bei Ihrer Frau, Ihren Kindern, Ihrer Mutter, Ihrer Großmutter abholen oder im schlimmsten Fall unter der Türmatte hervorholen. Wir empfehlen daher, dass Sie immer eine Ersatzkennung haben und diese beispielsweise in einem Safe aufbewahren.
Wenn wir über die Wiederherstellung des Zugriffs auf Dienste sprechen, ist dies wirklich ein schwieriges Problem. Die Wiederherstellung ist nicht Teil des Standards, da verschiedene Ressourcen den Zugriff auf Konten auf unterschiedliche Weise wiederherstellen. Klassische Ansätze sind Einmalcodes, die nicht vor Phishing geschützt sind. Facebook ermöglicht es Ihnen, über Freunde wieder Zugang zu erhalten.
Die bisher vielversprechendste Lösung ist
Delegated Recovery - ein Wiederherstellungsprotokoll, das auf der Speicherung verschlüsselter Geheimnisse in anderen Diensten basiert. Es wurde übrigens von einem der Schöpfer von U2F Bratt Hill (Bratt Hill) geschrieben. Die Wiederherstellung ist ein ziemlich schwieriges und interessantes Problem, dessen Lösung noch zu finden ist.
Der private Schlüssel im Authentifikator muss kopiergeschützt sein. In welcher Form und wo werden Bezeichner gespeichert? Wie werden sie ausgetauscht?
Bei jeder Registrierung generiert der Authentifikator ein neues eindeutiges Schlüsselpaar und weist ihm eine zufällige Kennung zu, die als Anmeldeinformations-ID oder Anmelde-ID bezeichnet wird. Private Schlüssel werden in einem sicheren Speicher wie SecureEnclave, TPM oder TEE gespeichert.
Der private Schlüssel verlässt den Authentifikator nie, da dies nicht erforderlich ist. Wenn der Benutzer einen weiteren Authentifikator hinzufügen möchte, registriert er ihn einfach, generiert ein neues Schlüsselpaar und eine neue Kennung und überträgt den öffentlichen Schlüssel mit der Kennung an die Site. Während der Authentifizierung übersetzt die Site die Kennung in den Authentifikator, und der Authentifikator findet das Schlüsselpaar damit und signiert den Anruf.
In welcher Beziehung steht der neue Standard zu den Anforderungen der Datenschutzgesetze (z. B. DSGVO)?
Unsere Grundsätze stimmen sehr gut mit der DSGVO überein. Selbst im Zwei-Faktor-Modus machen wir die Phishing-Authentifizierung sicher. Wenn es sich um eine passwortlose Authentifizierung handelt, werden hier überhaupt keine Passwörter übertragen. Darüber hinaus kann unser Protokoll im Gegensatz zu Client-Zertifikaten nicht als Super-Cookies verwendet werden. Daher arbeiten viele Unternehmen bereits an der Implementierung unserer Protokolle.
Und wer setzt den Standard bereits um?
Google, Facebook, Dropbox, Salesforce, Bank of America, NTT Docomo ... Wir haben Hunderte von Unternehmen und eine halbe Milliarde Nutzer pro Tag. Wir wachsen jeden Tag. Der Wechsel zur vollständigen kennwortlosen Authentifizierung dauert jedoch einige Zeit.
Wie schnell erlaubt der Standard den Übergang von einer anderen Authentifizierungsmethode?
Der Wechsel von vorhandenen Zwei-Faktor-Authentifizierungslösungen (z. B. von OTP) zu FIDO ist recht einfach. Sie müssen nur die Bibliothek verbinden und einige Änderungen auf der Clientseite implementieren. In FIDO2 ist die Option zur kennwortlosen Authentifizierung nur ein zusätzliches Flag bei der Registrierung. Die Übertragung des gesamten Ökosystems auf die vollständige kennwortlose Authentifizierung dauert einige Zeit. Wir gehen davon aus, dass dieser Übergang in 10 Jahren 80% aller Dienstleistungen abschließen wird.
Welche Pläne hat FIDO zur Entwicklung des Standards? Welche Verbesserungen sind in naher Zukunft geplant? Und auf lange Sicht?
Bisher haben wir uns auf die Förderung von Standards konzentriert. Es gibt Millionen von Standorten auf der Welt - das bedeutet, dass wir eine Million Dinge zu tun haben. Langfristig planen wir die Implementierung von Standards für das Internet der Dinge, um die Sicherheit von IoT-Geräten zu erhöhen. Die Pläne umfassen auch Arbeiten an staatlichen Authentifizierungssystemen, eIDs, Pässen und dezentralen Identifikationssystemen.
Wie wollen Sie weiter an WebAuthn arbeiten? Wie kann Ihnen die IT-Community helfen?
Nach wie vor setze ich meine Arbeit als Botschafter in der Entwicklergemeinde fort: Ich veröffentliche Artikel, arbeite an Open Source, mache Präsentationen und führe Schulungen durch. In Bezug auf die Community-Hilfe kann ich nur sagen: „Wir brauchen mehr Open Source-Gold.“
PS Yuri Akkermann hat auch einen Artikel über Habré vorbereitet, in dem er die wichtigsten Sicherheitsmechanismen von FIDO2 beschrieb und die JS-API für die Arbeit damit überprüfte.