Was ist der beste Weg, Webformular Authentifizierungsdaten über HTTP senden?

https://stackoverflow.com/questions/715348

23-08-2019
|

Frage

Eine Firma, die ich weiß, ist in der Diskussion sein Passwort Sicherheitspolitik über alle ihre Web-Anwendung Produkte zu festigen.

Im Moment sie senden Benutzername / Passwort-Authentifizierung in POST Formen über HTTP, und somit werden sie unverschlüsselt übertragen werden.

Die einfachste Lösung für das Problem einfach ist HTTPS über alle unsere Anwendungen für die Anmeldung benötigt, nicht wahr?

Nun, es gibt einige interne Diskussion über stattdessen eine Art von Roll-unsere-eigenen clientseitige Verschlüsselung von Passwörtern zu tun (Passwort + Salz, etc.).

Gibt es eine akzeptierte HTTP-only Lösung?

Meinungen sind wie ... na ja, jeder eine Meinung hat, so dass ich bin auf der Suche nach glaubwürdiger Sicherheits Literatur, die Ihre Empfehlung unterstützen kann. Nicht nur Google und mich zu einer Blog-Post schicken ... Ich habe bereits die und weiter gemacht.

Ich habe OWASP Empfehlungen gefunden: http://www.owasp.org/index.php/Top_10_2007-A7# Schutz

Neben Microsoft: http://msdn.microsoft.com/en-us/library/aa302420. aspx

EDIT: Ihre Empfehlung gibt für die Verwendung von SSL ist nicht genug. Ich brauche eine Art von Dokumentation zu unterstützen. Ich weiß, dass unsere eigene Client-Seite Verschlüsselung rollt schlecht ist. Ich muss in der Lage sein, um glaubhaft, dass Mitarbeiter und Management zu verkaufen.

Auch HTTP Digest wurde erwähnt. Scheint nett, aber Digest ist nur für HTTP-Authentifizierung und nicht für Daten, die über POST gesendet.

Lösung

1 bis Mehrdad Antwort . Gehen voran mit home-grown-Kryptographie ist riskant.

aus Erfahrung hier, nach eigener Anbau clientseitige Verschlüsselungslösungen gesehen Schwachstellen aufweisen. Die meisten der Schwachstellen sind wegen des gleichen Grunde - die Datenübertragung durch Verschlüsselung mit einem geheimen Schlüssel geschützt, aber der Schlüssel selbst wurde in einer unsicheren Art und Weise ausgetauscht

TLS / SSL löst das Problem nicht nur Schlüsselaustausch sichern, sondern auch eine sichere Datenübertragung.

TLS / SSL schützt Ihre sensiblen Daten durch assymmetric Key-Kryptographie mit dem symmetrischen Schlüssel verwendet zum Austausch von Informationen hin und her zu verschlüsseln, sobald die TLS / SSL-Sitzung hergestellt wurde. Der symmetrische Schlüssel wird zur Laufzeit erzeugt und ein gemeinsames Geheimnis zwischen dem Client und dem Server; es ist dieser Schlüssel, der verwendet wird, alle anderen Datenverkehr zu verschlüsseln, sobald die Sitzung für die Übertragung von Daten bereit ist.

Der Servers Öffentliche und private Schlüssel nur zum Austausch von diesem gemeinsamen geheimen Schlüssel verwendet. Die einzige bekannte Art und Weise den gemeinsamen Schlüssel zu Kompromissen ist der Server des privaten Schlüssels beeinträchtigen (so dass der geheime Schlüssel kann dann entschlüsselt werden). In Wirklichkeit erfordert es Fahrlässigkeit oder Vorsatz auf Seiten des Server-Administrator.

Wenn Sie eine eigene Verschlüsselungslösung rollen, müssen Sie den symmetrischen Schlüssel, auf sichere Weise auszutauschen Der einfachste Weg, dies zu tun ist, TLS / SSL zu verwenden; desto schwieriger Weg ist, Ihre eigene assymmetric Schlüsselaustausch Kryptographie-Lösung zu implementieren.

Andere Tipps

ich hoch empfehlen gegen mit Ihrer eigenen Lösung gehen (in sicherheitssensiblen Umgebungen). Gehen Sie mit SSL. Es ist eine bewährte Technologie, und es ist einfach zu implementieren.

Ihre eigenen Sicherheitslösungen Roll können wirklich gefährlich sein, und selbst wenn es richtig (0.000001% Chance) implementiert ist, ist es teuer sein.

Wenn die Daten selbst ist nicht zu empfindlich, aber die Passwörter sind, würde ich vorschlagen, mit HTTP Digest-Authentifizierung (das ist ein ganz anderes Tier von HTTP-Basisauthentifizierungs ist). Es ist ziemlich sicher über gerade HTTP, und nicht schwer auf dem Server zu implementieren. Es wird nichts über den Draht geschickt, die zeigen konnten, was das Passwort ist, nur Informationen, die der Client mit dem Server demonstrieren kann, dass sie das richtige Passwort haben.

Wenn Sie eine anständige Erklärung, wie HTTP zu implementieren Digest-Authentifizierung in Ihrer Anwendung, Paul James hat einen hervorragenden Artikel über sie .

Das einzige wirkliche Problem mit HTTP-Authentifizierung ist in den Browsern selbst: die UI ist schrecklich, aber das kann sein mit einigen Javascript überwinden.

Sie können die Passwörter sicher speichern, indem Sie den A1-Hash zu speichern.

UPDATE:. Wie in anderen Antworten erwähnt, während der Server kann MITM Angriffe durch nicht akzeptieren Grund Auth vermeiden, ist der Kunde immer noch anfällig, weil es

UPDATE:. Sie können keine Daten über POST sichern, wenn Sie entweder (a) tun Verschlüsselung in JavaScript auf dem Client oder, (b) alles über SSL

Sie können , mit ein wenig Magie, Verwendung HTTP Auth mit Formularen. Der Artikel, den ich oben verlinkt ist ‚HTTP Auth mit HTML-Formularen‘, schließlich genannt. Aber das wird nicht über POST durchgeführt werden.

Wenn Sie wirklich müssen sie POST verwenden, die Verwendung von SSL und Salz, die Passwörter in der Datenbank.

Wenn Sie CSRF wollen vermeiden, empfehle ich formkeys , wenn die Idee von vielen geht verschiedene Namen, nahm ich ein paar Jahre zurück, dass die Namen von Hacking Slash für meinen eigenen Gebrauch nach oben, das ist, wo ich über sie kam zuerst.

Sie haben mehr Zeit und Geld ausgeben, Ihre eigene Lösung rollen und nicht sicher sein, dass es sicher ist. Industrie-Standard-SSL ist einfach zu implementieren und weitaus sicherer aus der Box, als Sie sich leisten können, eine eigene Lösung zu machen.

Zeit == Geld

Kaufen Sie ein Zertifikat und verbringen Sie Ihre Zeit auf Ihrer Anwendung arbeiten, anstatt ein sicheren Login-Formulars.

Die clientseitige Verschlüsselung ist hilflos gegen die meisten MITM-Angriffe. Angreifer können einfach Ihr Skript entfernen.

Es wird nur gegen passiven Sniffing schützen. Wenn das für Sie gut genug ist, können Sie:

Hashing in Javascript umgesetzt. Es ist einfach, Challenge-Response für Erstanmeldung zu implementieren, aber nicht vergessen, dass für Angreifer Session-Cookie als Passwort fast so gut ist (man müßte Login auf einzelne IP begrenzen und / oder Skript verwendet einmalige Cookie erzeugen für jede Anfrage, die ich mir vorstellen, wäre schwierig und spröde Lösung).
HTTP Digest-Authentifizierung. Sicherer, da es eine einmalige Hashes, die gegenseitige Authentifizierung verwenden kann, etc., aber Standard-UI ist absolut abstoßend.

... nur SSL verwenden.

HTTP nur Lösungen werden immer anfällig für Man-in-the-Middle-Angriffe.

EDIT:. Eine Netzwerk-Trace wäre eine einfache Möglichkeit, dass HTTP zu beweisen, ist nicht sicher

Okay, hier ist die einzige Antwort, die Sie brauchen: Ihre BANK unterstützt nur Login / Auth über SSL. Gäbe es einen besseren Weg, es zu tun, sie würden.

Nun, es gibt einige interne Diskussion um stattdessen tun irgendeine Art von Roll-unser-eigene clientseitige Verschlüsselung Passwörter (Passwort + Salz, usw.).

Das erste, was wir angehen müssen, ist, Daten während der Übertragung gegen ruhende Daten. Vom OP klingt es wie die große Sorge Benutzername / Passwort im Klartext über das Internet ist. So sorgen Sie sich wirklich über Daten im Transit. HTTPS über SSL ist eine bewährte Methode, dies zu tun (und es ist eine ziemlich einfache Lösung!). Nun, wenn Sie wirklich für ruhende Daten Ihre eigene Rolle wollen (in einem DB, auf einem Dateiserver, etc.), das ist ein anderes Tier, aber die bestehenden Methoden zur Datenverschlüsselung werden besser sein als eine Rolle Ihrer eigenen .

Unter Berufung auf der Client-Seite für Ihre Sicherheit ist schlecht. Zeitraum. In einer Unternehmensumgebung, ja, können Sie etwas auf einem Standard-Setup verlassen. Aber letztlich sind die Benutzer stumm und Sie können in jemanden zu deaktivieren Javascript ausführen oder was auch immer Client-basierte Lösung Sie ausrollen, so dass sie am Ende des Benutzername / Passwort im Klartext senden sowieso (auch wenn die Server nicht‘wissen, was damit zu tun weil es nicht das erwartete Format ist.

Roll-your-own wird nicht auf die Kontrolle unterliegt, die eine bestehende Lösung. Sie könnten zusätzliche Sicherheitsfragen in die Mischung aufgrund des Code am Ende hinzufügen.

Wir löschte nur eine Web / Mobile App einige dieser Dinge zu tun. Es werden zufällige URLs für Anmeldungen, über HTTPS und eine Hash / AES Verschlüsselungsmethode für die Datenbankspeicher. Theres eine einfache JSON API ohne unsere UI zu verwenden, heren unsere writeup, geben Sie ihm einen Blick .. http://blog.primestudiosllc.com/security/send-time-limited-secure-logins-with-timebomb-it

Sie Ihre eigene Verschlüsselung und Salz erwähnt tun ... Ich schlage vor, mit Javascript md5 (es auch von yahoo auf ihren nicht ssl Seiten verwendet wird, oder er behauptet, so) ...

Und Sie doppelte Haschisch das Passwort ... argumentieren einige, dass Doppel es Hashing wäre es zu Kollision Angriffe anfällig machen. Ich muß nicht zustimmen, weil Menschen in der Lage gewesen, bis jetzt MD5-Signatur Kollisionen auf Dateien nur zu tun, bei denen große Datenmenge md5'ed ...

Wenn es eine große Unternehmens-Website (und würde es Gründe geben, zu brechen), gibt es keine Entschuldigung, nicht SSL verwendet wird.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow