it-swarm.com.de

Ist es möglich, einen GPG- oder SSH-Schlüssel für die webbasierte Authentifizierung auf sichere Weise zu verwenden?

Nehmen wir an, ich schreibe hypothetisch eine Webanwendung für technisch versierte, sicherheitsbewusste Benutzer, die keine Probleme beim Generieren und Verwenden von GPG- oder SSH-Schlüsseln haben.

Ist es möglich, diese Schlüssel zur sicheren Authentifizierung bei einer Webanwendung zu verwenden, um die herkömmliche kennwortbasierte Authentifizierung zu ersetzen?

Wie sehen die Authentifizierungsschritte aus, wenn dies möglich ist? Gibt es vielleicht eine bekannte gute Implementierung einer solchen Idee für beliebte Sprachen und Plattformen wie Ruby, .NET, Java oder Python)?

Wenn es nicht möglich ist, was sind die Gründe? Gibt es möglicherweise eine Einschränkung für Webbrowser, die auf den GPG-Schlüsselbund oder die SSH-Schlüsseldatei zugreifen?

36
user10211

Bei einer Webanwendung besteht das Hauptproblem darin, dass der Website-Code (Javascript in einem Browser) Dateien nicht nach Belieben lesen und schreiben kann. Im Allgemeinen ist dies eher ein Segen als ein Problem, aber hier bedeutet dies, dass der Javascript-Code nicht auf private SSH- oder PGP-Schlüssel zugreifen kann.

Es gibt Dinge, die getan werden können, abhängig davon, wie technisch versiert Ihre Benutzer sind und wie viele manuelle Vorgänge sie tolerieren:

  • Sie können eine lokal installierte Browsererweiterung verwenden, die im Namen der Website auf die privaten SSH- oder PGP-Schlüssel zugreift. Vorzugsweise ist eine gewisse Benutzersteuerung ratsam: Wir wollen wirklich keinen Browser, der Dinge signiert, nur weil eine Website dies vorschreibt.

  • Der Server kann als SSH-Server fungieren und erfordert, dass Clients eine Verbindung mit SSH und der schlüsselbasierten Clientauthentifizierung herstellen. Der Benutzer würde SSH im "SOCKS-Proxy" -Modus ausführen. Der Webserver selbst würde nur localhost abhören, d. H. Nur über einen solchen lokalen Proxy erreichbar sein. In diesem Modus kann der Webserver sogar HTTP und nicht HTTPS sein. Dies würde wirklich SSL durch SSH ersetzen. Auf der Serverseite sollte das Verfolgen von Benutzern mod_ident oder ähnliches verwenden (der SSH-Server weiß, wer der Client ist, aber die Informationen müssen an den HTTP-Server weitergeleitet werden; zum Glück ist dies derselbe Maschine, damit die Identität auf Unix-Ebene verwendet werden kann).

  • Die Website könnte eine "Herausforderung" als herunterladbare Datei mit zufälligen Inhalten anzeigen. Der Benutzer erhält die Datei, signiert sie mit GnuPG und fügt die (ASCII-gepanzerte) Ausgabe in ein Textfeld auf der Website ein. Der Server überprüft die Signatur und akzeptiert sie als Authentifizierung des Benutzers (vorausgesetzt, der Server kennt den öffentlichen Schlüssel des Benutzers bereits). Klobig, funktioniert aber.

Eine E-Mail-basierte Variante der oben genannten Methode kann ratsam sein, da PGP-Implementierungen häufig in E-Mail-Software eingebettet sind und die Möglichkeit besteht, einer externen Stammzertifizierungsstelle nicht vertrauen zu müssen. Es würde so aussehen:

  • Der Benutzer stellt über HTTPS eine Verbindung zum Webserver her. Der Server verwendet ein selbstsigniertes Zertifikat. Der Browser warnt davor (die "rote Gruselwarnung"), ermöglicht dem Benutzer jedoch, fortzufahren.

  • Auf der Site gibt der Benutzer seinen Namen ein. Anschließend sendet der Server eine signierte und verschlüsselte E-Mail (mit PGP) an den Benutzer. Die signierte E-Mail enthält eine zufällige Nonce sowie eine Kopie des Fingerabdrucks des SSL-Zertifikats des Servers. Die zufällige Nonce wird auch auf der Website selbst ausgedruckt.

  • Der Benutzer überprüft die PGP-Signatur in der E-Mail des Servers und überprüft dann, ob der Fingerabdruck mit dem übereinstimmt, den er in seinem Browser sehen kann. Dies überzeugt den Benutzer davon, dass er das echte Serverzertifikat sieht, sodass kein Man-in-the-Middle-Angriff ausgeführt wird. (Hier ersetzen wir das X.509-CA-System durch eine PGP-basierte Validierung.)

  • Der Benutzer überprüft außerdem, ob die auf der Website angezeigte Nonce mit der in der E-Mail angezeigten übereinstimmt (dies ist wichtig).

  • Der Benutzer antwortet auf die E-Mail, indem er den Inhalt zurücksendet, diesmal mit seinem eigenen privaten PGP-Schlüssel signiert und mit dem öffentlichen Schlüssel des Servers verschlüsselt. Der Server überprüft diese E-Mail und weiß somit, dass der Nonce-Wert tatsächlich vom beabsichtigten Benutzer empfangen wurde.

  • Der Server sendet den Nonce-Wert als Cookie an den Browser des Benutzers. Dies ermöglicht das Surfen, ohne den Benutzer mit weiteren Authentifizierungsrunden zu belästigen. Es ist Sache des Servers, zu entscheiden, wie lange er das Cookie als gültiges Authentifizierungstoken akzeptiert.

Bei dem obigen Schema ist es wichtig zu beachten, dass der Benutzer durch das Zurücksenden seiner E-Mail-Antwort den Server tatsächlich autorisiert, anzunehmen, dass derjenige, der mit der Nonce zurückkommt (wie in der E-Mail enthalten), wirklich der Benutzer selbst ist. Aus diesem Grund ist es wichtig, manuell zu überprüfen, ob das Nonce mit dem übereinstimmt, was auf der Webseite angezeigt wird.

17
Thomas Pornin

Ist es möglich, OpenPGP/SSH-Schlüsselpaare zur sicheren Authentifizierung bei einer Webanwendung zu verwenden, um die herkömmliche kennwortbasierte Authentifizierung zu ersetzen?

Ja. Es ist ziemlich machbar.

Wie sehen die Authentifizierungsschritte aus, wenn dies möglich ist? Gibt es vielleicht eine bekannte gute Implementierung einer solchen Idee für beliebte Sprachen und Plattformen wie Ruby, .NET, Java oder Python?

Siehe meine Antwort für die nächste Frage.

Wenn es nicht möglich ist, was sind die Gründe? Gibt es möglicherweise eine Einschränkung für Webbrowser, die auf den GPG-Schlüsselbund oder die SSH-Schlüsseldatei zugreifen?

Die Verarbeitung von SSH- und OpenPGP-Schlüsseln in einer Webanwendung ist mit Bibliotheken von Drittanbietern möglich (insbesondere C- oder Java -Bibliotheken aufgrund ihrer umfassenden Ökologie), aber Sie würden die Nutzung der gängigsten vorhandenen Lösung verpassen - SSL/TLS.

Am besten generieren Benutzer ein von Ihrem Server signiertes X509-Clientzertifikat, um sich zu authentifizieren. Dann kann sich Ihre Webanwendung einfach auf den Webcontainer (Catalina Tomcat, ApacheD, IIS usw.) verlassen, um eine nahtlose Verschlüsselung und Authentifizierung für Sie durchzuführen Anwendung.

Unter der Haube haben OpenPGP-Schlüssel dieselben RSA-Exponenten wie ein X509-Zertifikat, sodass Tools wie openssl GPG/PGP-Schlüssel in selbstsignierte * X509-Zertifikate konvertieren können. Gleiches gilt für SSH-Schlüssel .

* OpenPGP-Web-of-Trust wird vom X509-Standpunkt aus als "selbstsigniert" eingestuft, da X509v3 keine Vertrauensbasis mit mehreren Wurzeln haben kann, soweit ich dies feststellen konnte.

8
LateralFractal

Die vorhandenen Antworten bieten gute Ratschläge - verwenden Sie stattdessen den SSL-Stack im Browser.

Es ist jedoch tatsächlich möglich, genau das zu tun, was Sie wollen - mithilfe der JavaScript-Kryptografie.

Es gibt eine OpenPGP-Implementierung in JavaScript http://openpgpjs.org/ Ich kann nicht für die Qualität bürgen.

Es ist auch möglich, dass HTML5-JavaScript auf lokale Dateien zugreift, z. http://www.html5rocks.com/de/tutorials/file/dndfiles/

Ich denke, dies wäre eher eine Kuriosität als ein praktisches System.

4
paj28