Nur-Text-Passwort über HTTPS

90

Ich arbeite derzeit an einem PHP OpenID-Anbieter, der über HTTPS (daher SSL-verschlüsselt) funktioniert.
Ist es falsch für mich, das Passwort als Klartext zu übermitteln? HTTPS kann theoretisch nicht abgefangen werden, daher sehe ich nichts falsches. Oder ist das auf einer bestimmten Ebene unsicher und ich sehe das nicht?

https password-protection

— WhyNotHugo
quelle

125

Es ist sicher. So funktioniert das gesamte Web. Alle Passwörter in Formularen werden immer im Klartext gesendet, daher liegt es an HTTPS, sie zu sichern.

— Eduardo Scoz
quelle

19

Kleiner Nitpick: Einige Anmeldeformulare verwenden JavaScript, um das Passwort zu hashen, anstatt es im Klartext zu senden.

— Thorarin

5

@Thorarin Wenn sie es wirklich hashen, bedeutet dies, dass der Server das Passwort im Klartext speichert, damit er mit demselben Salz hashen kann, um es zu überprüfen. Ick! Das Senden des Kennworts in SSL-Text ist besser, da der Server das Kennwort dann nicht im Klartext speichern muss.

— DGM

11

@DGM: Doppel-Hashing ist ebenfalls eine Option, sodass Klartext-Passwörter nicht unbedingt erforderlich sind.

— Thorarin

3

@Denis: Client-seitiges Hashing hilft nicht wirklich viel. Es mag die Dinge etwas schwieriger machen als einfacher Text, aber jemand, der wirklich ein Passwort stehlen möchte, kann dies ohne Probleme tun. Nur würde sicher funktionieren, wenn Sie mindestens ein einmaliges Token über einen sicheren Kanal (ssl) senden. In diesem Fall können Sie das Kennwort zunächst auch einfach in SSL senden.

— Eduardo Scoz

4

Ich sage nur, dass Yahoo der Meinung war, dass das clientseitige Hashing sicher genug war, bis sie es sich leisten konnten, den ganzen Weg zu ssl zu wechseln. Aber hey, ich bin alles für https :)

— Denis

73

Sie müssen weiterhin sicherstellen, dass Sie es per POST-Anfrage senden, nicht per GET. Wenn Sie es per GET-Anfrage senden, kann es im Klartext in den Browserverlaufsprotokollen des Benutzers oder in den Zugriffsprotokollen des Webservers gespeichert werden.

— niemand
quelle

7

Ja, das wusste ich, aber es ist immer noch ein guter Kommentar für andere, die hierher kommen. :)

— WhyNotHugo

oder senden Sie es in einem Header

— James

22

Wenn HTTP deaktiviert ist und Sie nur HTTPS verwenden, übertragen Sie das Kennwort ohnehin nicht wirklich als Klartext.

— Kann Berk Güder
quelle

4

Der Server hat jedoch Zugriff auf Ihr Klartext-Passwort. Er kann es als Klartext speichern, falsch als Klartext protokollieren usw. Das heißt, Ihr Passwort bleibt nicht auf der Clientseite, der Server sieht auch genau, was es ist.

— XRef

13

Hash-Client-Seite. Warum? Lassen Sie mich Ihnen von einem kleinen Experiment erzählen. Gehen Sie in der Cafeteria des Unternehmens zum Computer. Öffnen Sie den Browser für die Anmeldeseite der Unternehmenswebsite (https). Drücken Sie F12, klicken Sie auf die Registerkarte "Netzwerk", deaktivieren Sie "Persist Log", minimieren Sie die Konsole, lassen Sie die Webseite jedoch für die Anmeldeseite geöffnet. Setzen Sie sich und essen Sie zu Mittag. Beobachten Sie, wie sich ein Mitarbeiter nach der Anmeldung auf der Unternehmenswebsite anmeldet und sich als guter kleiner Mitarbeiter abmeldet, wenn er fertig ist. Beenden Sie das Mittagessen, setzen Sie sich an den Computer, rufen Sie die Registerkarte "Netzwerk" auf und sehen Sie jeden einzelnen Benutzernamen und jedes Kennwort im Klartext in der Form "bodys".

Keine speziellen Tools, keine speziellen Kenntnisse, keine ausgefallene Hacking-Hardware, keine Keylogger, nur gute alte F12.

Aber hey, denken Sie weiter, alles was Sie brauchen ist SSL. Die Bösen werden dich dafür lieben.

— CodeDog
quelle

5

Ihr Cafeteria-Kommentar macht keinen Sinn, egal wie oft ich ihn noch einmal lese. Warum gehen die Leute einfach zu einem Computer und geben ihre Anmeldeinformationen ein? Was versuchst du zu beweisen? Auch Hashing nicht diese machen mehr unsicher, in keiner Weise. Es war üblich, Passwörter zu

— hashen

4

Ich upvoted beides , weil, ja, die akzeptierte Antwort wird viele Jahre später gelesen werden. Es wäre gut, wenn @CodeDog auf eine Strategie zur Schadensbegrenzung hinweisen würde. Und ja, die Leute gehen einfach zu zufälligen PCs, zum Beispiel in der örtlichen Bibliothek, und geben ihre Daten ein!

— JoeAC

3

Ich verschlüssle Passwörter clientseitig mit einem öffentlichen Schlüssel und poste dann nur das verschlüsselte Passwort im Formular. Da es sich um einen asymmetrischen Schlüssel handelt, ist es für die Angreifer nutzlos, den clientseitigen öffentlichen Schlüssel zu haben. Jedes Protokoll generiert ein neues Schlüsselpaar, sodass Wiederholungsangriffe auch nicht funktionieren. Der Schlüssel ändert sich sogar bei fehlgeschlagenen Anmeldeversuchen. Die Schlüsselpaare werden serverseitig generiert, wenn die Benutzer zum Anmeldebildschirm gelangen. Für den clientseitigen Code wird nur der öffentliche Schlüssel bereitgestellt.

— CodeDog

Übrigens habe ich gesehen, dass dieser Hack in einem Hotel-Businesscenter von Mitarbeitern verwendet wird, um Passcodes für Zimmernummern zu sammeln. Sie würden den Passcode verwenden, um auf das WLAN zuzugreifen und die Business-Center-PCs zu verwenden, und es würde dem Zimmer in Rechnung gestellt.

— CodeDog

Ich habe ein solches Experiment selbst durchgeführt, indem ich mich in mein Bankkonto eingeloggt habe, und muss mit @CodeDog übereinstimmen. Die Nutzdaten müssen sowohl mein Login als auch mein Passwort im Klartext enthalten.

— Artur Michajluk

6

Machen wir uns einige Notizen zu früheren Antworten.

Erstens ist es wahrscheinlich nicht die beste Idee, Hash-Algorithmen clientseitig zu verwenden. Wenn Ihr Kennwort auf der Serverseite gesalzen ist, können Sie keine Hashes vergleichen (zumindest nicht, wenn Sie den Client-Hash nicht in der Datenbank in einer der Hash-Ebenen des Kennworts speichern, die identisch sind oder schlechter). Und Sie möchten den von der Datenbank auf der Clientseite verwendeten Hashing-Algorithmus nicht implementieren, es wäre dumm.

Zweitens ist es auch nicht ideal, kryptografische Schlüssel auszutauschen. Das MITM könnte theoretisch (wenn man bedenkt, dass auf dem Client ein Stammzertifikat installiert ist) die kryptografischen Schlüssel ändern und mit seinen eigenen Schlüsseln ändern:

Ursprüngliche Verbindung (ohne Berücksichtigung von tls) von einem theoretischen Server, der Schlüssel austauscht:

Öffentliche Schlüssel für Clientanforderung> Server enthält die privaten Schlüssel, generiert öffentliche Schlüssel für Client> Server sendet öffentliche Schlüssel an Client

Nun, in einem theoretischen MITM-Atrack:

Öffentliche Schlüssel für Clientanfragen > MITM generiert gefälschte private Schlüssel > Server hält die privaten Schlüssel, generiert öffentliche Schlüssel für den Client> MITM empfängt die öffentlichen Schlüssel vom ursprünglichen Server. Jetzt können wir unsere gefälschten öffentlichen Schlüssel an den Client senden Wenn eine Anfrage vom Client kommt, entschlüsseln wir die Clientdaten mit den gefälschten Schlüsseln, ändern die Nutzdaten (oder lesen sie) und verschlüsseln sie mit den ursprünglichen öffentlichen Schlüsseln. > MITM sendet gefälschte öffentliche Schlüssel an den Client.

Dies ist der Grund dafür, dass Sie ein vertrauenswürdiges CA-Zertifikat in TLS haben. Auf diese Weise erhalten Sie eine Warnung vom Browser, wenn das Zertifikat nicht gültig ist.

Als Antwort auf das OP: Meiner bescheidenen Meinung nach können Sie das nicht tun, weil früher oder später jemand einen Benutzer von Ihrem Dienst aus angreifen möchte und versucht, Ihr Protokoll zu brechen.

Sie können jedoch 2FA implementieren, um zu verhindern, dass Benutzer jemals versuchen, sich mit demselben Kennwort anzumelden. Vorsicht vor Wiederholungsangriffen.

Ich bin nicht besonders gut mit Kryptografie. Bitte korrigieren Sie mich, wenn ich falsch liege.

— Lucca Ferri
quelle

Denken Sie daran, dass diese Diskussion aus dem Jahr 2009 stammt. Dies waren zu dieser Zeit so ziemlich die besten Praktiken.

— WhyNotHugo

3

@WhyNotHugo Ich bin mir bewusst. Ich habe beschlossen, eine Antwort zu hinterlassen, da mich die beste Google-Antwort auf diese Frage hierher geführt hat. Warum also nicht?

— Lucca Ferri

4

Die anderen Poster sind korrekt. Jetzt, da Sie SSL verwenden, um die Übertragung des Passworts zu verschlüsseln , stellen Sie sicher, dass Sie es mit einem guten Algorithmus und Salt hashen, damit es auch im Ruhezustand geschützt ist ...

— Grossvogel
quelle

Ja, mir ist klar, danke, ich habe mich hier nur auf die Übertragung bezogen.

— WhyNotHugo