it-swarm.com.de

Login ohne HTTPS, wie sichern?

Ist es für eine Webapplikation möglich, die Anmeldung etwas sicherer zu machen, wenn HTTPS nicht als Sicherheitsmaßnahme verfügbar ist? Z.B.:

  • Tokenize Logins, um wiederholte Angriffe zu erschweren?
  • Das gesendete Passwort irgendwie aus einem HTML-Passwortfeld verschlüsseln?

Insbesondere verwende ich CakePHP und einen Aufruf von AJAX POST, um die Authentifizierung auszulösen (einschließlich des bereitgestellten Benutzernamens und des Kennworts).

Update zum Problem:

  • HTTPS ist nicht verfügbar. Zeitraum. Wenn Sie die Situation nicht mögen, betrachten Sie sie als theoretische Frage.
  • Es gibt keine expliziten Anforderungen, Sie haben alles, was HTTP, PHP und einen Browser (Cookies, JavaScript usw.) im wirklichen Leben bieten (keine magischen RSA-Binaries, PGP-Plugins).
  • Die Frage ist, was ist das Beste, was Sie aus dieser Situation machen können, das ist besser als das Senden der Passwörter im Klartext. Die Nachteile jeder dieser Lösungen zu kennen, ist ein Plus.
  • Jede Verbesserung besser als einfache Kennwörter ist willkommen. Wir streben keine 100% ige Lösung von l33tG0Dhx0r-proff an. Schwierig zu knacken ist besser als kompliziert zu hacken, was besser ist als ein banales Schnüffeln, das das Passwort enthüllt.
73
sibidiba

HTTPS ist für die Aufrechterhaltung einer sicheren Verbindung zwischen einer Website und einem Browser unbedingt erforderlich . Öffentliche WLAN-Netzwerke gefährden Benutzer , und bei richtiger Verwendung ist HTTPS das einzige Tool , das Benutzerkonten vor - schützen kann. diese Sicherheitsanfälligkeit .

Wenn Ihr Host HTTPS nicht unterstützt, können Sie mit einem Dienst wie Cloudflare Universal SSL sicherstellen, dass alle Browser über HTTPS eine Verbindung zu Ihrer Site herstellen , auch wenn dies auf Ihrem Server nicht der Fall ist Unterstützt SSL/TLS . Die Verbindung zwischen Cloudflare und Ihrer Website ist weiterhin ungeschützt. Dieser Cloudflare-Dienst soll Benutzer jedoch vor Bedrohungen schützen, die in öffentlichen WLAN-Netzwerken auftreten. Aus der Sicht eines Penetrationstesters ist es höchst verdächtig, kein HTTPS bereitzustellen. Wenn Sie keine grundlegende Sicherheitsanforderung für die Bereitstellung von Datenverkehr stellen, welche anderen Sicherheitsanforderungen fehlen dann? HTTPS-Zertifikate können kostenlos mit Let's Encrypt ​​oder Start SSL bezogen werden. Es gibt keinen legitimen Grund, HTTPS nicht zu unterstützen.

HTTPS ist wichtig, da es viel mehr als nur "Passwörter verschlüsseln" kann. Eine weitere wichtige Rolle ist, dass der Benutzer daran gehindert werden soll, sich bei einem böswilligen Server anzumelden, der sich als echter Server ausgibt. Die alleinige Verwendung eines Systems zum Schutz des Kennworts verstößt nach wie vor gegen OWASP A9 - Unzureichender Schutz der Transportschicht , da Sie die Anmeldeinformationen der Sitzung weiterhin im Klartext übertragen würden, der alle vom Angreifer benötigten Informationen enthält ( Firesheep ).

  1. JavaScript-basierte Kryptografie kann nicht zum Erstellen einer sicheren Transportschicht verwendet werden .

  2. "Tokenize logins": Wenn ein Angreifer den Datenverkehr abfängt, hat er den Klartext-Benutzernamen/das Kennwort und kann sich dann einfach mit diesen neuen Anmeldeinformationen anmelden. (Angriff wiederholen)

  3. "Verschlüsseln Sie das übertragene Passwort irgendwie": Nachdem sich die Person eingeloggt hat, kann ein Angreifer den Datenverkehr abhören, um die gültige Sitzungs-ID (Cookie) und dann einfach zu erhalten Verwenden Sie diese Option, anstatt sich anzumelden. Wenn die gesamte Sitzung mit SSL/TLS geschützt war, ist dies kein Problem.

Es gibt andere komplexere Angriffe, die sowohl dieses System als auch unsere aktuelle SSL-Infrastruktur betreffen. Der SSLStrip Angriff wird detaillierter. Ich kann Moxie Marlinspikes Blackhat 2009 Talk ansehen wärmstens empfehlen, was zum HTTP-Strict-Transport-Security-Standard führte.

75
rook

Da Sie auf dem Webserver kein SSL ausführen können und kein Sicherheitsexperte sind, suchen Sie nach einem vorhandenen sicheren Authentifizierungsdienst, den Sie verwenden können, und lassen Sie ihn sowohl das SSL als auch die Komplexität der Verarbeitung von Anmeldeinformationen für Sie handhaben.

Insbesondere würde ich vorschlagen, dass Sie einen kostenlosen Authentifizierungsdienst eines Drittanbieters verwenden, z. B. OpenID . Sie haben Bibliotheken für PHP einschließlich einer für CakePHP .


Bearbeiten: (über Risiken)

Die Verwendung eines sicheren Authentifizierungsdienstes eines Drittanbieters (der HTTPS selbst verwendet) kann das Problem der Authentifizierung selbst ohne Verwendung von HTTPS (auf Ihrem Server) mindern, schließt jedoch die Möglichkeit von Angriffen nicht vollständig aus.

Die häufigsten zwei Angriffe sind Wiederholungsangriffe und Sitzungsentführungen , bei denen der Angreifer entweder einen echten erneut verwenden kann Melden Sie sich später als Sitzungs-Token an, oder verwenden Sie ein gültiges Sitzungs-Token für den eigenen böswilligen Zweck.

Der Wiederholungsangriff kann durch Ablaufen des Sitzungstokens und vorzugsweise durch Verwendung eines nonce abgeschwächt werden, um eine Wiederholung der Sitzung zu verhindern und das Risiko einer Sitzungsentführung zu verringern. Bei einem Nonce generiert eine legitime Sitzung einen Fehler, wenn sie erfolgreich entführt wurde, da das Nonce abgelaufen ist (verwendet wurde), sodass die eigene Sitzung nicht mehr gültig ist.

Wenn Sie HTTPS nicht zum Verschlüsseln des Sitzungstokens während der Übertragung von und zu Ihrem Server verwenden können, können Sie aktive Angriffe wie Session-Hijacking oder nicht vollständig verhindern. Man-in-the-Middle Angriff. Dies kann in einigen Fällen akzeptabel sein, z. B. bei Websites mit einer kleinen Benutzerbasis für nichtkommerzielle Zwecke.

16
mctylr

Die kurze Antwort lautet: Ohne SSL-Endpunkt und Endpunktverschlüsselung ist es unmöglich, dies sicher zu tun ...

Einer der Hauptgründe dafür ist, dass Sie Krypto nicht in einem Browser sichern können. Siehe diese Referenz - Javascript Kryptographie als schädlich .

Darüber hinaus können Sie nicht sicher sein, dass die Quelle der Anmeldeinformationen tatsächlich derjenige ist, mit dem Sie sprechen. Das heißt, es gibt absolut keinen Weg ohne SSL, um sicher zu gehen, dass es keinen Man-In-The-Middle-Angriff gibt .

Nein, du kannst es nicht tun. 

Versuchen Sie es auch nicht. Holen Sie sich SSL. Sie können kostenlose Zertifikate erhalten. Die Hosts geben Ihnen normalerweise eine bestimmte IP-Adresse für ein paar $$$ pro Monat. Und wenn Sie wirklich Wert auf Sicherheit legen, verwenden Sie sowieso mindestens eine VM mit einer dedizierten IP-Adresse. 

Dies sogar zu versuchen, wäre Sicherheit durch Unbekanntheit bestenfalls und nichts im schlimmsten Fall. SSL ist ein gelöstes Problem. Warum nicht diese Lösung verwenden? Sicherheit ist nicht zu erraten. Verwenden Sie die richtigen Techniken. Versuche nicht, deine eigenen zu erfinden. Es wird nicht funktionieren ...

14
ircmaxell

Wie Sie vorgeschlagen haben, können Sie möglicherweise jedes Mal ein eindeutiges Token generieren, wenn die Seite erstellt wird. Das gleiche Token müsste mit den Formulardaten zurückgesendet werden und könnte nicht wiederverwendet werden. Sie können das Kennwort auch schützen, indem Sie JavaScript verwenden, um es zu kennzeichnen, wenn Sie sich darauf verlassen können, dass es von Ihren Benutzern aktiviert wird. 

Dieses Schema ist jedoch immer noch nicht sicher. Ein Angreifer konnte immer noch alles über den Draht sehen. Sie könnten das Token abfangen und Ihnen eine Antwort zurücksenden, bevor der Benutzer dies tut. Oder sie warten nur darauf, dass sich jemand anmeldet, stehlen die Anmeldeinformationen dieser Person (da sie über die Leitung gesendet werden) und stellen später eine eigene Anmeldeanforderung.

Endeffekt - Sie müssen HTTPS verwenden, um die Sicherheit der Website zu gewährleisten.

13
Justin Ethier

Sie können das Passwort mit Javascript verschlüsseln und auf dem Server entschlüsseln.

Ich würde empfehlen, ein RSA-Schlüsselpaar auf dem Server zu generieren, den öffentlichen Schlüssel zusammen mit einem zeitgesteuerten Salt an den Browser zu senden und dann das Kennwort, kombiniert mit dem Salt, mit dem öffentlichen Schlüssel in Javascript zu verschlüsseln.

Eine RSA-Implementierung finden Sie in Javascript hier

Sie sollten sowohl die IP-Adresse als auch den gesamten X-FORWARDED-FOR hedaer in die Authentifizierungs-Cookies aufnehmen, um einen Diebstahl von Cookies hinter Proxys zu verhindern.

Wenn Sie mit vertraulichen Daten zu tun haben, können Sie einen zufälligen AES-Schlüssel in Javascript generieren und ihn zusammen mit dem mit RSA verschlüsselten Kennwort an den Server senden.
Sie könnten dann die gesamte Anwendung dazu verwenden, verschlüsselte AJAX -Anfragen von einer einzigen Seite aus zu verwenden und keinen Auth-Cookie zu verwenden.

Beachten Sie, dass ein Schutz gegen einen aktiven Man-in-the-Middle-Angriff ohne SSL nicht möglich ist. Ein aktiver Angreifer kann Ihre Site vollständig durch einen eigenen Proxy ersetzen, und dagegen gibt es keine Möglichkeit, sich dagegen zu wehren. (Da es keinen bekannten guten Code geben kann)

6
SLaks

Sie können HTTP Digest authentication verwenden, das von den meisten Browsern unterstützt wird und das Kennwort nicht eindeutig über die Verbindung sendet. 

Der Nachteil ist das hässliche Login-Feld, das von broswer angezeigt wird. Wenn Sie es vorziehen, bei Formularen zu bleiben, können Sie in der Formularauthentifizierung genau das gleiche Protokoll wie HTTP Digest implementieren: Senden Sie ausgeblendete Felder, die den Bereich und die Herausforderung enthalten, und lassen Sie den Client in JavaScript die Nonce hinzufügen und den Digest berechnen. Auf diese Weise verwenden Sie ein bekanntes und bewährtes Austauschprotokoll, anstatt Ihr eigenes Protokoll zu erstellen.

HTTP Digest erfordert nur Hash-Operationen.

6
Remus Rusanu

HTTPS verfügt über zahlreiche Anwendungsfälle, von denen die meisten zur Abwehr von Man-in-the-Middle-Angriffen entwickelt wurden. Jeder, der die Einstellung eines Hackers hat, wird schaudern, wenn er Ihnen sagt, dass es keinen anderen Weg gibt als den etablierten, etwas zu erreichen. Die Tatsache ist, dass nur, weil Sie TLS (den Standard, den modernes HTTPS verwendet), verwenden, nicht bedeutet, dass Sie es gut verwenden. Darüber hinaus hindert die Verwendung von TLS niemanden daran, bekannte Schwachstellen auszunutzen. So wie Sie vielleicht kreative Wege finden, um Ihre Daten zu schützen, gibt es Menschen, die kreative Wege finden, um Ihre Sicherheitsmaßnahmen auszunutzen.

Also, was ist zu tun?

Wenn Sie auf TLS verzichten möchten, ist es zunächst hilfreich zu verstehen, wie dies funktioniert. Und es geht um einen Handschlag.

Sobald der Client und der Server die Verwendung von TLS vereinbart haben, verhandeln sie eine zustandsbehaftete Verbindung mithilfe eines Handshake-Verfahrens. [7] Während dieses Handshakes einigen sich Client und Server auf verschiedene Parameter, mit denen die Sicherheit der Verbindung hergestellt wird:

  • Der Handshake beginnt, wenn ein Client eine Verbindung zu einem TLS-fähigen Server herstellt, um eine sichere Verbindung anzufordern, und zeigt eine Liste der unterstützten Cipher Suites (Chiffren und Hash-Funktionen) an.
  • Aus dieser Liste wählt der Server eine Verschlüsselungs- und Hash-Funktion aus, die er auch unterstützt, und benachrichtigt den Client über die Entscheidung.
  • Der Server sendet seine Identifikation in Form eines digitalen Zertifikats zurück. [Widerspruch] Das Zertifikat enthält normalerweise den Servernamen, die vertrauenswürdige Zertifizierungsstelle (CA) und den öffentlichen Verschlüsselungsschlüssel des Servers.
  • Der Client kann den Server kontaktieren, der das Zertifikat ausgestellt hat (die vertrauenswürdige Zertifizierungsstelle wie oben) und die Gültigkeit des Zertifikats bestätigen, bevor er fortfährt.
  • Um die für die sichere Verbindung verwendeten Sitzungsschlüssel zu generieren, verschlüsselt der Client eine Zufallszahl mit dem öffentlichen Schlüssel des Servers und sendet das Ergebnis an den Server. Nur der Server sollte es mit seinem privaten Schlüssel entschlüsseln können.
  • Aus der Zufallszahl generieren beide Parteien Schlüsselmaterial für die Ver- und Entschlüsselung. [Widerspruch] Dies beendet den Handshake und startet die gesicherte Verbindung, die mit dem Schlüsselmaterial ver- und entschlüsselt wird, bis die Verbindung geschlossen wird.

Wenn einer der obigen Schritte fehlschlägt, schlägt der TLS-Handshake fehl und die Verbindung wird nicht hergestellt.

Quelle: Wikipedia

Also ist es möglich? Ja. Mir wurde beigebracht, dass alles möglich ist. Es mag teuer sein, aber es ist immer möglich.

Ich möchte offenlegen, dass ich KEIN Sicherheitsexperte bin, sondern nur ein Enthusiast. Ich empfehle nicht, dies für ein Produktionsprojekt oder etwas anderes als Ihre eigene Erbauung zu versuchen. Sie sollten auf jeden Fall this SO post auschecken, das eine hervorragende Erklärung für Roadblocks beim Einrichten Ihres eigenen Sicherheitsprotokolls bietet.

Wenn Sie jedoch weitermachen möchten, kommen Ihnen hier einige Gedanken in den Sinn. Dies sind Realitäten, die existieren werden, unabhängig davon, welche direkte Entscheidung Sie für dieses Projekt getroffen haben.

  • HTTPS wird von allen gängigen modernen Browsern unterstützt. Trotz dieser Realität sind HTTPS-Ladezeiten langsamer als normales HTTP. Ohne eine umfangreiche Produktion ist Ihre alternative Implementierung höchstwahrscheinlich ein Bruchteil der Sicherheit, während sie erheblich langsamer ist. Dies ist ein Nachteil jeder hausgemachten Implementierung, es sei denn, Sie verwenden Browserfunktionen, wodurch sich der Kreis zurück zur Verwendung von TLS schließt, die das moderne HTTPS verwendet.

  • Wenn Sie es schaffen, Ihr Passwort ohne TLS auf der Browserseite mithilfe von Javascript so unvorhersehbar zu verschlüsseln, dass ein MiTM-Angriff schwierig wäre, sollten Sie sich nicht dort ausruhen. Sie sollten auch die Daten sichern, die Sie hin und her senden. Andernfalls ist das zu verschlüsselnde Passwort wirklich irrelevant. Natürlich kennt ein Angreifer das Passwort von bobsmith109 nicht, aber er benötigt es nicht, da er jede einzelne Aktivität im Netzwerk abhören kann. Er weiß, wann sich bobsmith109 anmeldet, kann wahrscheinlich seine IP und andere vertrauliche Daten, die Sie hin und her senden, nachverfolgen.

  • Unabhängig davon, welche Sicherheitsmaßnahmen Sie ergreifen, gibt es umfassende Sicherheitsmaßnahmen. Sie können also auf Anhieb sicherstellen, dass Sie Ihre Daten in der Datenbank verschlüsseln und gleichzeitig sichere Kennwörter benötigen.

Ich bekräftige, dass ich kein Sicherheitsexperte bin und von diesem nachdrücklich abrate alles andere als deine Neugier zu stillen. Es ist astronomisch unwahrscheinlich, dass Sie eine realisierbare Alternative zu TLS schaffen können, ohne dass eine außergewöhnlich große Gruppe von Sicherheitsexperten jahrelang, wenn nicht sogar jahrzehntelang, an einem Projekt mitwirkt. Dafür kann SSL/TLS stehen. Abgesehen davon ist ein guter Ausgangspunkt, wenn Sie fortfahren möchten, das Handshake-Modell oben zu betrachten und zu sehen, wie Sie eine Version ohne TLS implementieren können.

Es wäre mir ein Rätsel, in meinem Beitrag nicht mitzuteilen, dass die meisten realen Hemmnisse für die Verwendung von HTTPS aktiv bekämpft werden. Einer der größten - Kosten - steht kurz davor, kein Thema zu werden. Eine kostenlose Zertifizierungsstelle wird im 2. Quartal 2015 herauskommen, unterstützt von einigen großen Waffen, darunter Mozilla und Akamai, um nur einige zu nennen. Hier ist ein Artikel .

2
smcjones

Was ist mit HTTP Digest Authentication ? Es bietet Sicherheit durch den Benutzernamen, das Kennwort und eine Nonce (unter anderem) von MD5-Hash, bevor es an den Server gesendet wird. MD5 ist nicht wirklich sicher, aber es ist eine gute Möglichkeit für einfache Sicherheit mit HTTP.

Natürlich hindert dies Hacker nicht daran, die Nachricht zu ändern ... aber es schützt Ihr Passwort.

2
AndiDog

Login ohne HTTPS, wie sichern?

Da es keinen sicheren Kanal zwischen Ihrem Server und Ihrem Client gibt:

  • da es keinen sicheren Kanal gibt, kann jeder Ihren Datenverkehr ausnutzen.
  • da jeder den Verkehr ausnutzen kann, sind Sie offen für einen MITM-Angriff.
  • da Sie offen für MITM-Angriffe sind, gibt es keine Garantie dafür, dass Ihr Kunde eine legitime Seite sieht.
  • da die Seiten nicht legitim sind und Ihre Seite tatsächlich nicht bereitgestellt wird (der Typ in der Mitte bedient die Seiten), werden alle serverseitigen Tricks unbrauchbar.

Was kannst du tun? Theoretisch?

  • sowohl Client als auch Server müssen verschlüsselt werden, um das Snooping/MITM weniger anfällig zu machen.
  • gehe davon aus, dass du keinen Händedruck haben kannst,
  • nehmen Sie an, Ihr Client hat bereits Ihren Schlüssel und weiß, wie Sie Ihren Server sprechen.
  • wie wäre es mit etwas SSL über HTTP, das aber in base64-kodierte Nachrichten für ein Kauderwelsch verpackt ist?

Aber warten Sie ... Da Sie kein magisches Binär-Plugin oder kein Plugin oder auch nicht RSA sagten, weiß ich nicht, ob dies möglich ist, es sei denn (einige möglicherweise sehr schwache) interne Verschlüsselung.

-

1
dnozay

Sie können versuchen, es bis zu einem gewissen Punkt zu replizieren, indem Sie die Verschlüsselung mit öffentlichen Schlüsseln (möglicherweise GPG) und das Browser-Caching verwenden.

Dies ist nicht etwas Sicheres, selbst wenn Sie nur SSL einrichten, reicht dies für einen ausgereiften Angreifer nicht aus. Sie müssen HSTS, das Festlegen öffentlicher Schlüssel usw. verwenden, um eine Website als sicheres today zu betrachten.

Der Rest der Antwort ist nur Anlass zum Nachdenken. 

  1. Erstellen Sie ein Public-Private-Key-Paar. Bewahren Sie ein privates sicher.
  2. Erstellen Sie eine js-Datei, die den öffentlichen Schlüssel und eine encrypt-Funktion enthält, und suchen Sie nach einem sicheren Verschlüsselungsalgorithmus. Diese Funktion sollte eine gegebene Zeichenfolge (serialisierte Form) mit einem zusätzlichen Zeitstempel verschlüsseln, um einen Replikationsangriff zu vermeiden.
  3. Diese Datei mit Cache-Control:public, max-age=31536000 HTTP-Header bereitstellen. Wir versuchen zu entschärfen, wenn der Angreifer versucht, das Skript zu ersetzen. Die Datei wird immer vom Browser-Cache aus bereitgestellt. 
  4. Senden Sie alle Formulare mit der Funktion encrypt über Javascript. Servieren Sie diese mit dem gleichen Header wie oben.
  5. Überprüfen Sie auf der Serverseite decrypt die Daten, ob der Zeitstempel noch gültig ist. Tun Sie es, wenn nicht, werfen Sie es weg.
  6. Erstellen Sie ein Cookie-Token, das nur einmal für kurze Zeit verwendet werden kann. Wenn der Angreifer einen Cookie fängt, hat er nicht viel Zeit, um etwas zu erledigen. Wenn der Angreifer jedoch schnell genug ist, kann er den ursprünglichen Benutzer abmelden.
  7. Ändern Sie die Cookies mit jeder Antwort. Was tun Sie dann, wenn der Benutzer mehrere Anforderungen gleichzeitig sendet und diese dann in umgekehrter Reihenfolge eintreffen? Welcher Cookie ist gültig? Dies führt zu Tonnen von Problemen, die auf Kosten eines falschen Sicherheitsgefühls entstehen.

Die Listener können die Daten nicht verwenden, die hin und her gehen, und sie können die vorhandenen JS -Dateien nicht ändern/einfügen, bis der Cache abläuft/der Benutzer den Cache löscht. Jeder erfahrene Angreifer kann jedoch die gesamte HTML-Datei ersetzen, wodurch alle soeben erwähnten Sicherheitsmaßnahmen verworfen werden. Wenn Sie diese Datei/dieses Formular zumindest über HTTPS bereitstellen können, könnten Sie mit [] davonkommen, sie auf Github-Seiten oder was auch immer ablegen. Wenn Sie die Datei jedoch in eine andere Domäne setzen, müssen Sie CORS für die empfangende Domäne einrichten, damit dies funktioniert.

Noch ein Versuch

Einmalige Passwörter an E-Mail gesendet.

  1. Der Benutzer füllt seine E-Mail aus und klickt auf einen Link, der einen Link mit einem Token an die E-Mail sendet, mit dem er sich anmelden kann.
  2. Der Benutzer klickt auf den Link
  3. Der Server überprüft das Token und meldet den Benutzer an.
  4. Rollt die Cookies wie im vorherigen Beispiel.

Alles in allem, was auch immer Sie tun, es ist nicht sicher . Dem schnellen, raffinierten Angreifer steht nichts im Wege.

Holen Sie sich SSL, wenn die Infrastruktur es nicht unterstützt, ändern Sie es. Wenn Ihr Manager nicht an SSL glaubt, überzeugen Sie ihn. Schaffen Sie kein falsches Sicherheitsgefühl. Schützen Sie die Daten Ihres Benutzers. Je nach Ihrem Standort sind Sie gesetzlich dazu verpflichtet, die Daten Ihrer Benutzer zu schützen.

Dann sprechen wir darüber, wie Sie eine Site mit SSL schützen können.

1
Umur Kontacı

Erstellen Sie ein öffentliches/privates Schlüsselpaar unter Verwendung einer asymmetrischen Chiffre.

Erstellen Sie einen symmetrischen Schlüssel auf dem Server.

Senden Sie den öffentlichen Schlüssel an die Clientseite.

Erstellen Sie einen zufälligen Schlüssel für die symmetrische Chiffrierseite.

Verschlüsseln Sie diesen zufälligen Schlüssel mit der Seite des öffentlichen Schlüssels.

Senden Sie den verschlüsselten Schlüssel an den Server.


Server führt Folgendes aus:

ein. Entschlüsselt den symmetrischen Zufallsschlüssel mit dem privaten Schlüssel.

b. Erstellt ein Token, das den generierten Clientschlüssel enthält.

c. Signiert das Token.

d. Verschlüsselt das Token mit dem symmetrischen Server-Schlüssel.

e. Verschlüsselt das bereits verschlüsselte Token mit dem vom Client generierten Schlüssel.

f. Sendet das verschlüsselte Token nach unten.


Der Client erhält dieses Token und führt Folgendes aus:

ein. Entschlüsselt das Token mit dem generierten Schlüssel.

b. Speichert das entschlüsselte Token.

c. An diesem Punkt wird das gespeicherte Token nur mit dem symmetrischen Server-Schlüssel verschlüsselt.


Auf jedem vom Client zum Server:

ein. Verschlüsseln Sie die ausgehenden Daten mit dem vom Client generierten Schlüssel.

b. Senden Sie das Token + verschlüsselte Daten


Bei jeder Anfrage erhält der Server:

ein. Entschlüsseln Sie das Token mit dem symmetrischen Server-Schlüssel.

b. Überprüfen Sie die Signatur.

c. Entschlüsseln Sie die Daten mit dem vom Client generierten Schlüssel, der im Token gespeichert ist.

0
Hedzer

Schauen Sie sich "The Secure Remote Password Protocol" an.

Lassen Sie mich, anstatt es selbst zu formulieren, aus ihrer Website zitieren:

Das Secure Remote Password-Protokoll führt eine sichere Remote-Authentifizierung von kurzen, für den Menschen erkennbaren Passwörtern durch und verhindert sowohl passive als auch aktive Netzwerkangriffe.

und:

[Das] Protokoll kombiniert Techniken des Zero-Knowledge-Beweises mit Protokollen für den asymmetrischen Schlüsselaustausch und bietet eine erheblich verbesserte Leistung gegenüber vergleichsweise starken erweiterten Methoden, die Angriffen mit gestohlenen Verifizierern wie Augmented EKE oder B-SPEKE widerstehen.

Obwohl die Stanford University keine Implementierungen für PHP und JavaScript selbst bereitstellt, sind sie mit Implementierungen von Drittanbietern verknüpft.

Einer dieser Links führt zu "Clipperz", einem Online-Passwortmanager. Es ist auch als Community Edition auf GitHub verfügbar. Dort hosten sie ihre "javascript-crypto-library" , die das Protokoll implementiert, und den "password-manager" selbst, der Backends enthält, die in PHP und Python geschrieben sind.

Ich kann nicht sagen, wie schwierig es wäre, die relevanten Teile des Codes zu extrahieren, aber vielleicht können Sie deren Implementierung wiederverwenden (sie ist unter AGPL lizenziert).

Edit 2014/10/24:

Wikipedia-Artikel zu SRP listet einige weitere Implementierungen auf. Relevant für PHP/JS:

0
ben