Login ohne HTTPS, wie sichern?

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

• Token-Logins, um wiederholte Angriffe zu erschweren?
• Verschlüsseln Sie das gesendete Passwort irgendwie aus einem HTML-Passwortfeld?

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

Update zum Problem:

• HTTPS ist nicht verfügbar. Zeitraum. Wenn Ihnen die Situation nicht gefällt, betrachten Sie sie als theoretische Frage.
• Es gibt keine expliziten Anforderungen, Sie haben alles, was HTTP, PHP und ein Browser (Cookies, JavaScript usw.) im wirklichen Leben bieten (keine magischen RSA-Binärdateien, 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, die besser ist als einfache Passwörter, ist willkommen. Wir streben keine 100% ige l33tG0Dhx0r-proff-Lösung an. Schwer zu knacken ist besser als kompliziert zu hacken, was besser ist als ein triviales Schnüffeln, das das Passwort enthüllt.

HTTPS ist für die Aufrechterhaltung einer sicheren Verbindung zwischen einer Website und einem Browser von entscheidender Bedeutung. Öffentliche WLAN-Netzwerke gefährden Benutzer. Bei korrekter Verwendung ist HTTPS das einzige Tool , das Benutzerkonten vor dieser Sicherheitsanfälligkeit schützen kann .

Wenn Ihr Host HTTPS nicht unterstützt, kann ein Dienst wie Cloudflare Universal SSL verwendet werden, um sicherzustellen, dass alle Browser über HTTPS eine Verbindung zu Ihrer Site herstellen, auch wenn Ihr Server SSL / TLS nicht unterstützt . Die Verbindung zwischen Cloudflare und Ihrer Website bleibt 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 sehr verdächtig, kein HTTPS bereitzustellen. Wenn Sie keine grundlegende Sicherheitsanforderung für die Bereitstellung von Datenverkehr bereitstellen, welche anderen Sicherheitsanforderungen fehlen Ihnen 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 besteht darin, zu verhindern, dass sich der Benutzer bei einem böswilligen Server anmeldet, der sich als echter Server ausgibt. Die Verwendung eines Systems zum alleinigen Schutz des Kennworts stellt immer noch eine Verletzung von OWASP A9 - Unzureichender Transportschichtschutz dar, da Sie weiterhin Sitzungsanmeldeinformationen im Klartext übertragen würden, was alles ist, was der Angreifer benötigt ( Firesheep ).

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

2. "Token-Anmeldungen": Wenn ein Angreifer den Datenverkehr abhört, hat er den Benutzernamen / das Kennwort im Klartext und kann sich dann einfach mit diesen neuen Anmeldeinformationen anmelden. (Wiederholungsangriff)

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

Es gibt andere komplexere Angriffe, die sowohl dieses System als auch unsere aktuelle SSL-Infrastruktur betreffen. Der SSLStrip- Angriff wird detaillierter. Ich empfehle dringend , Moxie Marlinspikes Blackhat 2009-Vortrag zu sehen , der zum HTTP-Strict-Transport-Security-Standard führt .

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

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

Darüber hinaus können Sie nicht sicher sein, dass die Quelle der Anmeldeinformationen tatsächlich die ist, mit der Sie sprechen. Das bedeutet, dass es ohne SSL absolut keine Möglichkeit gibt, sicher zu sein, dass kein Man-In-The-Middle-Angriff stattfindet .

Also nein, du kannst es nicht tun.

Versuchen Sie es außerdem nicht einmal. Holen Sie sich SSL. Sie können kostenlose Zertifikate erhalten. Hosts geben Ihnen normalerweise eine dedizierte IP für ein paar $$$ pro Monat. Und wenn Sie sich wirklich um Sicherheit kümmern, würden Sie sowieso mindestens eine VM mit einer dedizierten IP-Adresse verwenden.

Dies überhaupt zu versuchen, wäre bestenfalls Sicherheit durch Dunkelheit und im schlimmsten Fall nichts. 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 ...

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 übernehmen.

Insbesondere würde ich vorschlagen, dass Sie einen kostenlosen Authentifizierungsdienst eines Drittanbieters wie OpenID verwenden . Sie haben Bibliotheken für PHP, darunter eine 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) verringern, 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 später ein echtes Anmeldesitzungstoken wiederverwenden oder ein gültiges Sitzungstoken für seinen eigenen böswilligen Zweck verwenden kann.

Der Wiederholungsangriff kann gemindert werden, indem das Sitzungstoken abläuft und vorzugsweise ein Nonce verwendet wird , um die Sitzungswiederholung zu verhindern und das Risiko einer Sitzungsentführung zu verringern. Bei einer Nonce generiert eine legitime Sitzung einen Fehler, wenn sie erfolgreich entführt wurde, da die Nonce abgelaufen ist (verwendet wurde) und ihre 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 Sitzungsentführung oder Man-in-the-Middle- Angriff nicht vollständig verhindern . Dies kann in einigen Fällen akzeptabel sein, z. B. bei Websites mit einer kleinen Benutzerbasis für nichtkommerzielle Zwecke.

Wie Sie vorgeschlagen haben, können Sie möglicherweise bei jeder Erstellung der Seite ein eindeutiges Token generieren. 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 zum Hashing verwenden, 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 laufen sehen. Sie könnten das Token abfangen und eine Antwort an Sie zurücksenden, bevor der Benutzer dies tut. Oder sie können einfach darauf warten, dass sich jemand anmeldet, die Anmeldeinformationen dieser Person stehlen (wenn sie über die Leitung gesendet werden) und später einfach ihre eigene Anmeldeanforderung stellen.

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

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 in Kombination mit dem Salt mit dem öffentlichen Schlüssel in Javascript zu verschlüsseln.

Eine RSA-Implementierung in Javascript finden Sie hier

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

Wenn Sie mit sensiblen Daten arbeiten, können Sie einen Zufall generieren AES-Schlüssel in Javascript und ihn dann zusammen mit dem mit RSA verschlüsselten Kennwort an den Server senden.
Sie können dann die gesamte Anwendung dazu bringen, verschlüsselte AJAX-Anforderungen von einer einzelnen Seite aus zu verwenden und überhaupt kein Auth-Cookie zu verwenden.

Beachten Sie, dass es ohne SSL nicht möglich ist, sich vor einem aktiven Man-in-the-Middle-Angriff zu schützen. Ein aktiver Angreifer kann Ihre Site vollständig durch seinen eigenen Proxy ersetzen, und es gibt keine Möglichkeit, sich dagegen zu verteidigen. (Da kein guter Code bekannt ist)

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

Der Nachteil ist das hässliche Anmeldefeld, das von broswer angezeigt wird. Wenn Sie sich lieber an Formulare halten, können Sie genau dasselbe Protokoll wie HTTP Digest in Ihrer Formularauthentifizierung implementieren: Senden Sie versteckte Felder, die den Bereich und die Herausforderung enthalten, und lassen Sie den Client das Nonce in JavaScript 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.

Was ist mit der HTTP Digest-Authentifizierung ? ? Es bietet Sicherheit durch MD5-Hashing-Benutzernamen, Passwort und eine Nonce (unter anderem), bevor es an den Server gesendet wird. MD5 ist nicht wirklich sicher, aber es ist ein guter Weg für einfache Sicherheit mit HTTP.

Dies hindert Hacker natürlich nicht daran, die Nachricht zu ändern ... aber es sichert Ihr Passwort.

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. Tatsache ist, dass nur weil Sie TLS (den Standard, den modernes HTTPS verwendet) verwenden, dies nicht bedeutet, dass Sie es gut verwenden. Darüber hinaus hindert die bloße Verwendung von TLS niemanden daran, bekannte Schwachstellen auszunutzen. So wie Sie möglicherweise kreative Wege finden, um Ihre Daten zu schützen, gibt es Menschen, die kreative Wege finden, um Ihre Sicherheitsmaßnahmen auszunutzen.

Also, was tun?

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

Sobald sich Client und Server auf die Verwendung von TLS geeinigt haben, verhandeln sie mithilfe eines Handshake-Verfahrens eine zustandsbehaftete Verbindung. [7] Während dieses Handshakes vereinbaren Client und Server 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 und eine sichere Verbindung anfordert und eine Liste der unterstützten Cipher Suites (Chiffren und Hash-Funktionen) anzeigt.
• Aus dieser Liste wählt der Server eine Verschlüsselungs- und Hash-Funktion aus, die er ebenfalls 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 sich an den Server wenden, 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] Damit ist der Handshake abgeschlossen und die gesicherte Verbindung wird gestartet, die mit dem Schlüsselmaterial verschlüsselt und entschlüsselt wird, bis die Verbindung geschlossen wird.

Wenn einer der oben genannten 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 vollständig 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 diesen SO-Beitrag lesen der eine hervorragende Erklärung für Hindernisse bei der Einrichtung Ihres eigenen Sicherheitsprotokolls bietet.

Wenn Sie jedoch weitermachen möchten, sind hier einige Gedanken, die Ihnen in den Sinn kommen. Dies sind Realitäten, die existieren werden, unabhängig davon, welchen direkten Weg Sie mit diesem Projekt gegangen sind.

• HTTPS wird von allen gängigen modernen Browsern unterstützt. Trotz dieser Realität sind die HTTPS-Ladezeiten langsamer als bei normalem HTTP. Ohne umfangreiche Produktion ist es sehr wahrscheinlich, dass Ihre alternative Implementierung einen Bruchteil so sicher ist und gleichzeitig erheblich langsamer. Dies ist ein Nachteil jeder selbst erstellten Implementierung, es sei denn, Sie verwenden Browserfunktionen. Dadurch schließt sich der Kreis zurück zur Verwendung von TLS, wie es das moderne HTTPS verwendet.

• Wenn Sie es schaffen, Ihr Passwort ohne TLS auf der Browserseite mit Javascript so unvorhersehbar zu verschlüsseln, dass ein MiTM-Angriff schwierig wäre, ruhen Sie sich nicht dort aus. Sie sollten auch die Daten sichern, die Sie hin und her senden. Ansonsten ist das zu verschlüsselnde Passwort wirklich irrelevant. Sicher, ein Angreifer kennt das Passwort von bobsmith109 möglicherweise nicht, benötigt es jedoch nicht, da er jede einzelne Aktivität im Netzwerk abhören kann. Er weiß, wann sich bobsmith109 anmeldet, kann wahrscheinlich seine IP und alle anderen vertraulichen Daten verfolgen, die Sie hin und her senden.

• Unabhängig davon, welche Sicherheitsmaßnahmen Sie ergreifen, gibt es umfassende Sicherheit. Eine Sache, die Sie sofort tun können, ist sicherzustellen, dass Sie Ihre Daten in der Datenbank verschlüsseln und gleichzeitig sichere Passwörter benötigen.

Ich bekräftige, dass ich kein Sicherheitsexperte bin, und rate davon nachdrücklich davon ab , Ihre Neugier zu stillen. Es ist astronomisch unwahrscheinlich, dass Sie eine praktikable Alternative zu TLS schaffen können, ohne dass eine außerordentlich große Gruppe von Sicherheitsexperten jahrelang, wenn nicht jahrzehntelang an einem Projekt beteiligt ist. Dies kann SSL / TLS vorweisen. Ein guter Ausgangspunkt für die weitere Vorgehensweise ist jedoch, das obige Handshake-Modell zu betrachten und zu prüfen, wie Sie eine Version davon ohne TLS implementieren können.

Ich möchte nicht in meinem Beitrag mitteilen, dass die meisten realen Hindernisse 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 und von einigen großen Waffen unterstützt werden, darunter Mozilla und Akamai, um nur einige zu nennen. Hier ist ein Artikel .

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 abhören.
• Da jeder den Datenverkehr abhören kann, sind Sie offen für einen MITM-Angriff.
• Da Sie für MITM-Angriffe offen sind, gibt es keine Garantie dafür, dass Ihr Client eine legitime Seite sieht.
• Da die Seiten nicht legitim sind und Ihre Seite tatsächlich nicht bereitgestellt wird (der Typ in der Mitte stellt die Seiten bereit), werden alle serverseitig verwendeten Tricks unbrauchbar.

Was kannst du tun? Theoretisch?

• Sowohl Client als auch Server müssen Verschlüsselung verwenden, um Snooping / MITM weniger anfällig zu machen.
• Angenommen, Sie können keinen Handschlag haben.
• Angenommen, Ihr Client verfügt bereits über Ihren Schlüssel und weiß, wie man denselben Kauderwelsch wie Ihr Server spricht.
• Wie wäre es mit etwas SSL über HTTP, das jedoch in eine Base64-codierte Nachricht für etwas Kauderwelsch eingeschlossen ist?

Aber warte ... Da du gesagt hast, dass es keine magische Binärdatei oder kein Plugin gibt, nicht einmal RSA, weiß ich nicht, ob dies möglich ist, außer für (einige möglicherweise sehr schwache) interne Verschlüsselung.

- -

Sie können versuchen, es zu einem bestimmten Zeitpunkt zu replizieren, indem Sie die Verschlüsselung mit öffentlichem Schlüssel (möglicherweise GPG) verwenden und das Browser-Caching verwenden.

Dies ist nicht sicher, selbst das Einrichten von SSL reicht für einen erfahrenen Angreifer nicht aus. Sie müssen HSTS, Pinning mit öffentlichen Schlüsseln usw. verwenden, um eine Website heute als sicher zu betrachten .

Der Rest der Antwort ist nur ein Denkanstoß.

1. Erstellen Sie ein öffentlich-privates Schlüsselpaar. Halten Sie privat sicher.
2. Erstellen Sie eine JS-Datei mit dem öffentlichen Schlüssel und einer encryptFunktion und suchen Sie einen sicheren Verschlüsselungsalgorithmus. Diese Funktion sollte eine bestimmte Zeichenfolge (serialisierte Form) mit einem zusätzlichen Zeitstempel verschlüsseln, um einen Replikationsangriff zu vermeiden.
3. Servieren Sie diese Datei mit Cache-Control:public, max-age=31536000HTTP-Header. Wir versuchen zu mildern, wenn der Angreifer versucht, das Skript zu ersetzen. Die Datei wird immer aus dem Browser-Cache bereitgestellt.
4. Senden Sie alle Formulare mit der encryptFunktion über Javascript . Servieren Sie diese mit dem gleichen Header wie oben.
5. decryptÜberprüfen Sie auf der Serverseite der Daten den Zeitstempel, ob er noch gültig ist. Wenn nicht, verwerfen Sie es.
6. Erstellen Sie ein Cookie-Token, das nur einmal für sehr kurze Zeit verwendet werden kann. Wenn der Angreifer einen Cookie erfasst, hat er nicht viel Zeit, um Dinge zu tun. Wenn der Angreifer jedoch schnell genug ist, kann er den ursprünglichen Benutzer abmelden.
7. Ändern Sie die Cookies bei jeder Antwort. Aber was machen Sie dann, wenn der Benutzer mehrere Anfragen gleichzeitig sendet und diese dann in umgekehrter Reihenfolge eintreffen? Welcher Cookie ist gültig? Dies schafft Unmengen von Problemen auf Kosten eines falschen Sicherheitsgefühls.

Listener können die hin und her gehenden Daten nicht verwenden und die vorhandenen JS Dateien erst ändern / einfügen , wenn der Cache abläuft / der Benutzer den Cache löscht. Jeder hoch entwickelte Angreifer kann jedoch die gesamte HTMLDatei ersetzen, wodurch alle soeben erwähnten Sicherheitsmaßnahmen verworfen werden. Wenn Sie diese Datei / dieses Formular zumindest bereitstellen können HTTPS, können Sie damit durchkommen, sie auf Github-Seiten oder was auch immer platzieren. Wenn Sie der Datei jedoch eine andere Domäne hinzufügen, müssen Sie CORSdie empfangende Domäne einrichten, damit dies funktioniert.

Noch ein Versuch

Einmalkennwörter per E-Mail gesendet.

1. Der Benutzer füllt seine E-Mail aus, klickt auf einen Link, der dann einen Link zu seiner E-Mail mit einem Token sendet, mit dem er sich anmelden kann.
2. 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 ist alles, was Sie tun, nicht sicher . Bei einem schnellen, hoch entwickelten Angreifer steht nichts mehr im Wege.

Holen Sie sich SSL, wenn die Infrastruktur dies 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. Abhängig von Ihrem Standort sind Sie gesetzlich verpflichtet, die Daten Ihrer Benutzer zu schützen.

Lassen Sie uns dann darüber sprechen, wie Sie eine Site mit SSL sicher machen.

Erstellen Sie ein öffentliches / privates Schlüsselpaar mit einer asymmetrischen Verschlüsselung.

Erstellen Sie einen symmetrischen Schlüssel auf dem Server.

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

Erstellen Sie einen Zufallsschlüssel für die Client-Seite mit symmetrischer Verschlüsselung.

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

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

Der Server führt Folgendes aus:

ein. Entschlüsselt den zufälligen symmetrischen Schlüssel mit dem privaten Schlüssel.

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

c. Unterzeichnet den Token.

d. Verschlüsselt das Token mit dem Server-Symmetrieschlü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 folgende Schritte aus:

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

b. Speichert das entschlüsselte Token.

c. Zu diesem Zeitpunkt wird das gespeicherte Token nur mit dem Server-Symmetrieschlü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 Server-Symmetrieschlü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.

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

Anstatt es selbst zu formulieren, möchte ich aus ihrer Website zitieren:

Das Secure Remote Password-Protokoll führt eine sichere Remote-Authentifizierung für kurze, vom Menschen einprägsame Kennwörter durch und widersteht sowohl passiven als auch aktiven Netzwerkangriffen.

und:

Das [The] -Protokoll kombiniert Techniken von Zero-Knowledge-Proofs mit asymmetrischen Schlüsselaustauschprotokollen und bietet eine deutlich verbesserte Leistung gegenüber vergleichsweise stark erweiterten Methoden, die Angriffen mit gestohlenen Verifizierern wie Augmented EKE oder B-SPEKE widerstehen.

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

Einer dieser Links führt zu "Clipperz" , einem Online-Passwort-Manager. 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 in PHP und Python geschriebene Backends enthält.

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

Bearbeiten 24.10.2014:

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

• srp-client (JS)
• srp-6a-demo (PHP / JS)

Die beste Lösung, die ich für etwas sichere HTTP-Verbindungen gesehen habe, ist die Verwendung einer Javascript-Implementierung von md5sum (oder eines anderen Hashs), um die Übertragung des Kennworts im Klartext zu vermeiden. Sie können einen Formular-Onsubmit-Handler in Javascript erstellen, der das Kennwortfeld durch einen Hash des ursprünglichen Werts ersetzt. Dies erhöht die Sicherheit einer unsicheren Verbindung in bescheidenem Maße, setzt jedoch voraus, dass Javascript im Browser ausgeführt wird, um ordnungsgemäß zu funktionieren.

Ich denke, Sie interessieren sich für die sichere Übertragung des Passworts an den Server? Meine Antwort lautet: Übertragen Sie keine Passwörter an den Server :)

Tatsächlich können Sie möglicherweise nichts vom Browser (Benutzer) zum Server übertragen, um den Benutzer zu authentifizieren, da ein Angreifer, der http-Verkehr ausspioniert, auch die Daten erneut übertragen und sich authentifizieren kann.

Vorschlag:

Eine offensichtliche Lösung wäre die Verwendung einer einmaligen Einweg-Transaktionsauthentifizierung, die vom Server ausgeht. wie eine Transaktionsnummer, die nur einmal verwendet werden kann. Schließlich benötigen Sie noch einmal einen sicheren Kanal, um die Liste der Transaktionsnummern mit dem Benutzer zu synchronisieren.

Sie könnten einen Google-Authentifikator verwenden , benötigen jedoch einmal einen sicheren Kanal, um die Parameter auf beiden Seiten einzurichten. Wenn Sie E-Mails als sicher betrachten, ist dies ein guter Weg.

Ich habe das gleiche Problem mit einem meiner Systeme. Ich habe Schritte unternommen, um die Sicherheit zu erhöhen, ohne die Benutzererfahrung durch verschlungene Mechanismen zu beeinträchtigen. Was mir auffiel, war, dass sich die überwiegende Mehrheit der Benutzer von demselben Computer mit demselben Browser (aber nicht unbedingt derselben IP-Adresse) oder von mehreren Browsern (z. B. Desktop oder Handy) aus anmeldete. Ich beschloss, damit ein Muster zu identifizieren.

1) Während der Registrierung müssen Benutzer über sichere Kennwörter (um Wörterbuchangriffe zu verhindern), eine Sicherheitsfrage / -antwort und eine Standard-E-Mail-Überprüfung (als Nachweis der realen Person) verfügen.

2) Während der Anmeldung wird nach 5 fehlgeschlagenen Anmeldeversuchen (nicht vorher) ein Captcha angezeigt, um Brute-Force-Angriffe zu verhindern.

3) Schließlich habe ich nach einer erfolgreichen Anmeldung einen Hash von Teilen der Benutzeragentenzeichenfolge erstellt, der das Betriebssystem des Benutzers, den Browser (im Allgemeinen keine Versionen) und die Sprache enthält und eine Art sekundäres Kennwort bildet. Wenn sich der Useragent-Hash bei der nächsten Anmeldung erheblich unterscheidet, wird der Benutzer aufgefordert, die Sicherheitsfrage zu beantworten. Wenn dies zufriedenstellend beantwortet wird, wird die neue UA-Zeichenfolge gehasht und zu ihrer Liste "sichere Maschinen" hinzugefügt, damit sie nicht erneut von dieser Maschine gefragt werden. Dies ähnelt einem Mechanismus, der vom Steam-Spielesystem verwendet wird.

Dies wird seit über einem Jahr mit etwa 700 Benutzern sehr erfolgreich verwendet und hatte den zusätzlichen Vorteil, dass die "Anmeldung freigegeben" wurde - ein Problem, bei dem mehrere Benutzer aus Bequemlichkeitsgründen dieselben Anmeldeinformationen verwendeten!

Die Antwort ist kürzer, und wenn Sie wirklich Wert auf Sicherheit legen, haben Sie immer Optionen auf verschiedenen Ebenen der Bürokratie.

Absolute Sicherheit gibt es nicht. Die Nummer eins Fehler ist immer auf der Client - Seite, mit Trojanern ans Keyloggern . SSL hilft dabei nicht.

1) Token-Generatoren : Banken verwenden sie, Blizzard verwendet sie dann. Es kann ein Gerät oder eine App sein. Nun ... es ist teuer.

2) SMS-Pins . interessante und erschwingliche Lösung. Es gibt viele gute Preise für SMS auf dem Markt und jeder hat ein Telefon, das sie empfangen kann.

3) Wenn Sie HTTP verwenden müssen, können Sie einen Drittanbieter-Dienst wie Google oder Facebook erzwingen . Das ist das Beste, was Sie ohne einen Token-Generator tun können.

Verwenden Sie Hashing-Mechanismen, um das Passwort zu speichern und das Hash-Passwort immer zu vergleichen. Dann kennt niemand das echte Passwort, auch Sie nicht. Es ist sehr einfach, aber es ist effektiv. Nichts ist jedoch völlig sicher und es gibt einige Möglichkeiten, die Reinheitsschichten aufzubrechen.

Wenn Sie HTTPS nicht verwenden können oder HTTPS nicht verwenden möchten, sollten Sie jCryption verwenden . jCryption bietet Verschlüsselung für die Daten, die über HTTP-Anforderungen (POST, GET usw.) gesendet werden.

Sie können die Technik hier testen: http://www.jcryption.org/#examples

Wenn Sie Firebug verwenden, werden Sie feststellen, dass alle Daten verschlüsselt sind.

Es verfügt über eine jQuery-Bibliothek zum Verschlüsseln der Daten im Front-End und eine PHP-Bibliothek zum Entschlüsseln der Daten im Back-End.

Versuchen Sie Folgendes: Senden Sie bei jeder Anforderung der Anmeldeseite eine Nonce und einen Zeitstempel. Senden Sie beim Posten auf dem Server die folgenden vier Details:

Der Benutzername, das Nonce und der Zeitstempel im Klartext. Verketten Sie dann das Obige mit einem Trennzeichen (z. B. newline) und verschlüsseln Sie es mit dem Kennwort des Benutzers als Verschlüsselung im Chained-Block-Cipher-Modus.

Verwenden Sie auf der Serverseite den Benutzernamen, um das Kennwort zu suchen und die verschlüsselte Zeichenfolge zu überprüfen.

Da das Passwort niemals eindeutig übermittelt wird, ist es sicher und der Zeitstempel kann verwendet werden, um eine erneute Übermittlung derselben Daten zu vermeiden.

Um eine Entführung der Sitzung durch Abrufen des Sitzungsschlüssels durch einen Man-in-the-Middle-Angriff zu vermeiden, kann das Kennwort oder ein Hash des Kennworts von der Anwendung auf der Clientseite im Speicher gespeichert und zum Generieren eindeutiger Sitzungsschlüssel verwendet werden zur Validierung durch den Server.

Ein Blick auf OAuth 1.0 ist ebenfalls keine schlechte Idee.

Es ist schwierig , die Kommunikation ohne ein zu sichern. Es trusted third partygibt jedoch einige Sicherheitstricks für Sie:

Setzen Sie die vertraulichen Informationen der Benutzer NICHT einem öffentlichen Netzwerk aus.

Alle vertraulichen Informationen sollten gut gehasht oder mit öffentlichen Schlüsseln verschlüsselt sein. Passt auf: Wenn Sie die vertraulichen Informationen der Benutzer mit einem öffentlichen Schlüssel verschlüsseln möchten, stellen Sie bitte sicher, dass der Benutzer den öffentlichen Schlüssel überprüfen kann. Sie können dem Benutzer beispielsweise eine Art Fingerabdruck mit öffentlichem Schlüssel per SMS oder sogar per automatischem Anruf senden.

Generieren Sie nach erfolgreicher Anmeldung ein SHARED SECRET

Nach einer sicheren Anmeldetransaktion sollte ein gemeinsames Geheimnis generiert werden. Das Generierungsverfahren könnte sich beziehen SSL Handshake. Achtung: Sobald das gemeinsame Geheimnis generiert ist, muss es weiter transportiert werden. Die einzige Funktion besteht darin, die Daten zwischen Serverund zu verschlüsseln / zu entschlüsselnBroswer

Es sollte eine Bestätigung in zwei Schritten erfolgen, um wiederholte Angriffe zu vermeiden

Mögen diese Tricks Ihnen helfen