it-swarm.com.de

Warum werden PGP- und SSH-Schlüssel bei der Authentifizierung nicht häufiger als zweiter Faktor verwendet?

Eine der wichtigsten aufstrebenden MFA-Methoden ist U2F, die auf einem anfänglichen Schlüsselaustausch- und Challenge-Response-Mechanismus beruht.

Es handelt sich um ein relativ neues Protokoll, das vor allem bei großen Web-Unternehmen wie Google immer häufiger eingesetzt wird. Es ist jedoch nicht der erste benutzerfreundliche Mechanismus, der Schlüssel austauscht und auf Herausforderungen reagiert. Tatsächlich fallen mir zwei leicht ein:

  • SSH, das es seit 1995 gibt und das im Wesentlichen auf jeder seit 2000 eingerichteten Linux- und BSD-Box verfügbar ist, wird unter Windows zunehmend über Add-On-Software in älteren Versionen und integrierte Software in neueren Versionen eingeführt. und

  • PGP, das es seit 1991 gibt und das tatsächlich auf einigen der neueren Yubikeys enthalten ist (wenn auch kontrovers mit einer Closed-Source-Implementierung in der neuesten Generation), sowie auf Millionen von PCs Weltweit mit zahlreichen hochwertigen, aktiv gewarteten Implementierungen und Bibliotheken für eine Vielzahl von Betriebssystemen.

Es scheint durchaus sinnvoll zu sein, eines dieser weit verbreiteten Protokolle/Standards als MFA-Mechanismus für mehr als nur SSHing in einen Remotecomputer oder das Verschlüsseln von E-Mails zu verwenden. Warum hat U2F auch dort, wo U2F boomt, keine Traktion gewonnen?

35
Jules

Schauen wir uns an, was PGP und SSH tatsächlich für diesen Zweck bieten:

  • PGP:
    Der Client muss PGP-Software installieren, die in den meisten Systemen nicht standardmäßig installiert ist. Der Client muss ein PGP-Schlüsselpaar erstellen. Anschließend muss er den öffentlichen Schlüssel an den Server senden, damit der Server ihn später zur Überprüfung verwenden kann. Bei der Authentifizierung bei 2FA sendet der Server eine Herausforderung, die der Client mit seinem privaten Schlüssel signieren und die signierte Herausforderung als Antwort zurücksenden muss. Natürlich muss der Kunde seinen Schlüssel vor Diebstahl schützen, möglicherweise mit einem Passwort.
  • SSH:
    Der Client muss die SSH-Software installieren, die in den meisten Systemen nicht standardmäßig installiert ist. Muss ein Schlüsselpaar erstellen und den öffentlichen Teil an den Server senden. Bei der Authentifizierung mit 2FA gegen einen Webdienst muss der Client eine SSH-Verbindung zu einem verwandten Server herstellen und der Server muss die erfolgreiche Authentifizierung mit SSH und die Anmeldung auf der Website irgendwie zusammenführen, möglicherweise mit einem zusätzlichen Token, das der Client nach der Verwendung geben muss SSH. Und oops, es könnte eine Firewall geben, die SSH blockiert. Und natürlich muss der Kunde den Schlüssel vor Diebstahl schützen.

Somit laufen im Wesentlichen beide Lösungen auf Folgendes hinaus:

  • installieren Sie zunächst eine Software
  • erstellen Sie ein statisches Schlüsselpaar und veröffentlichen Sie den öffentlichen Teil (dieser kann zur Vereinfachung in die Software integriert werden, ist dies jedoch derzeit nicht der Fall).
  • erhalten Sie irgendwie eine Herausforderung vom Server und senden Sie die signierte Herausforderung irgendwie zurück. Und irgendwie muss der Server die Validierung der Herausforderung in den Authentifizierungsprozess integrieren. "irgendwie", weil es dafür keinen bereits etablierten Prozess gibt, der alles in den in Webanwendungen verwendeten Authentifizierungsablauf integriert.
  • und natürlich muss der Kunde seinen Schlüssel schützen

Das gleiche Verfahren kann mit einem TLS-Zertifikat am Clientstandort viel einfacher durchgeführt werden. Dadurch bleibt die Erstellung des Zertifikats weiterhin ein großes Problem (dies ist jedoch auch heute im Browser möglich), aber zumindest die Validierung ist bereits in das HTTPS-Protokoll integriert.

Außerdem kann ich nicht sehen, wie diese Lösung eine bessere Benutzererfahrung oder Integrationserfahrung bietet als bestehende 2FA-Lösungen. Sie sind nicht einfach zu bedienen, erfordern zusätzliche Software, erfordern neue Möglichkeiten zur Integration in die Serverseite usw. Und sie bieten keine bessere Sicherheit auch nicht. Warum also die neueren Lösungen, die im Hinblick auf Benutzerfreundlichkeit und Serverintegration entwickelt wurden, nicht beachten?

Abgesehen davon verwenden die aktuellen billigen 2FA-Lösungen ein Mobiltelefon. Diese bieten normalerweise eine bessere Sicherheitsarchitektur als aktuelle PCs. Und sie sind ein zusätzliches Hardwaregerät, auf das der Benutzer Zugriff haben muss, wodurch der von 2FA gebotene Schutz verstärkt wird.

25
Steffen Ullrich

mangelnde Portabilität

SSH und PGP sind weit verbreitet, aber keine Webtechnologien. Es gibt seit vielen Jahren eine gleichwertige Web-Technologie - SSL-Client-Zertifikate. Dies wird jedoch nicht viel verwendet.

Der Grund ist die mangelnde Portabilität. Wenn Sie ein SSL-Client-Zertifikat auf Ihrem Heim-Desktop haben, ist es schwierig, es an einen anderen Ort zu verschieben. Sie können sich also nicht von Ihrem Arbeitslaptop, dem Desktop Ihrer Schwiegermutter usw. aus anmelden.

Es gibt eine tragbare Client-Zertifikatlösung, die es schon lange gibt und die eine sehr hohe Sicherheit bietet: Smartcards. Der private Schlüssel wird auf der Smartcard gespeichert und nie freigegeben. Dies wurde jedoch hauptsächlich in Hochsicherheitsanwendungen wie dem Online-Banking von Unternehmen eingesetzt.

In den frühen 2000er Jahren gab es nur begrenzte Innovationen im Bereich der Authentifizierung. Die auf den Massenmarkt ausgerichteten Bemühungen wie Microsoft Passport und OpenID nahmen nicht wirklich Fahrt auf. Die meisten Produkte waren auf das High-End-Gebiet ausgerichtet: Unternehmens-VPN-Zugang usw. Dies ändert sich jetzt und wir sehen Innovationen bei der Massenmarktauthentifizierung. Zum Beispiel:

  • Mozilla persona - Macht ein Client-Zertifikat im Wesentlichen portierbar, indem es in der Cloud gespeichert wird. Vor Jahren wäre dies als verrückte Idee abgelehnt worden, aber in letzter Zeit wird das Bedrohungsmodell besser verstanden und die Vorteile liegen auf der Hand.

  • 2F - Bringt die hohe Sicherheit von Smartcards auf den Massenmarkt. Die Geräte sind portabler und es ist sicher, ein Gerät auf vielen verschiedenen Websites zu verwenden. U2F ist also eine Technologie, die gut zu modernen Nutzungsmustern passt - daher ist sie erfolgreich.

11
paj28

Weil zusätzliche Authentifizierungsfaktoren im Idealfall außerhalb des Bandes liegen sollten. Wie ein Telefon oder ein Token oder eine Art telepathische Nachricht.

U2F ist gut, da Sie den privaten Schlüssel NICHT extrahieren können und das Gerät vor dem Signieren physisch berührt werden muss.

4
Dave

Für die breite Öffentlichkeit sollte jede 2-Faktor-Authentifizierung in weniger als 2 Minuten verstanden werden, da sie sonst sehr schnell fehlschlägt, da nur wenige Personen sie verstehen können. Das erfordert im Allgemeinen die Verwendung von etwas, mit dem die Leute bereits vertraut sind, oder ist sehr einfach.

PGP und SSH sind komplexe Technologien, die nur sehr wenige Menschen außer Entwicklern und IT-Mitarbeitern verstehen. Wie Stephen betont, müssen beide nicht nur die Software installieren, sondern auch sehr komplexe Methoden zum Generieren von Dateien, zum Senden an Dritte und (weitaus schlimmer) zum Verstehen der zugrunde liegenden Konzepte verstehen. Für die durchschnittliche Person würde dies viele Stunden Training, Versuch und Irrtum und völlig neue Konzepte erfordern. Selbst dann hätten Sie hohe Ausfallraten.

Vergleichen Sie dies mit den Lösungen, die in 2-Faktor verwendet werden. Textnachrichten, harte Token, auf denen Nummern angezeigt werden, oder Telefonanrufe. Textnachrichten und Telefonanrufe sind Dinge, mit denen Menschen bereits vertraut sind. Ein hartes Token ist etwas komplexer, aber ein Benutzer kann in weniger als 2 Minuten in der Verwendung dieser Geräte geschult werden, da sie einfach sind.

1
Steve Sether

Das EnigForm FireFox-Plugin war ein sehr vielversprechender Ansatz. In Kombination mit einer OpenPGP SmartCard war sie mindestens so sicher wie FIDO U2FA. Es ist schade, dass es keine breite Akzeptanz gefunden hat.

0
ulrichard

Zwei Dinge.

1. So war es schon immer

Biometrie oder Hardware-Token (wie RSA SecurID) waren der Standard für 2FA, und dann bekamen alle Handys und später Smartphones. Plötzlich war es einfach, einen zweiten Faktor zu schaffen, indem man Leuten eine E-Mail an ihr Smartphone oder an eine App auf ihrem Smartphone oder eine SMS an ältere Telefone schickte.

Dass Sie stattdessen eine Verschlüsselung mit öffentlichen Schlüsseln verwenden könnten, wurde nicht als zweiter Faktor angesehen, da Sie normalerweise öffentliche Schlüssel anstelle eines Kennworts verwendeten. Das war die Wahrnehmung der Menschen, und um ehrlich zu sein, hatte ich bis jetzt auch nicht viel darüber nachgedacht.

2. Es ist weniger sicher

Während eine Nachricht an eine App bereits leichter abgefangen werden kann als die RSA SecurID (oder Yubikey oder ein anderes Hardware-Token) und daher weniger sicher ist, ist die Verwendung der Authentifizierung mit öffentlichem Schlüssel wahrscheinlich noch weniger sicher:

Ein Token kann während der Eingabe abgefangen werden, aber Ihr privater Schlüssel kann ein für alle Mal von Ihrem Computer gestohlen werden. Die Quelle des zweiten Faktors befindet sich nicht auf einem Server (Senden von Textnachrichten) oder ist in einem manipulationssicheren Modul (einem Token) versteckt. Sie befindet sich im System, das Sie ständig für viele Dinge verwenden.

(Es muss angemerkt werden, dass Smartcards dieses Problem lösen, aber dann kenne ich wirklich wenige Leute, die das außerhalb der Arbeit verwenden.)


Die meisten anderen Antworten beinhalten auch "niemand hat das" in der einen oder anderen Form, und sie haben Recht. Aber die meisten Leute benutzen 2FA auch nicht. Ich denke, die Überschneidung zwischen Technikern, die SSH und/oder PGP und 2FA verwenden, ist erheblich und macht das Argument ungültig, dass niemand SSH, PGP oder ähnliches verwendet. Besonders Orte wie Github könnten SSH als zweiten Faktor anbieten. Sie unterstützen bereits SSH-Schlüssel (und Leute benutzen sie! ), nur nicht für 2FA.

0
Luc