Ich arbeite derzeit an einem PHP OpenID Provider, der über HTTPS funktioniert (daher SSL-verschlüsselt).
Ist es falsch für mich das Passwort als Nur-Text zu übertragen? HTTPS in der Theorie, kann nicht abgefangen werden, so sehe ich nichts falsch. Oder ist das auf einer bestimmten Ebene unsicher und ich sehe das nicht?Klartext Passwort über HTTPS
Es ist sicher. So funktioniert das gesamte Web. Alle Passwörter in Formularen werden immer im Klartext gesendet, daher ist es bis zu HTTPS zu sichern.
Wenn HTTP deaktiviert ist und Sie nur verwenden HTTPS, dann übertragen Sie nicht wirklich das Passwort als Klartext trotzdem.
Sie müssen immer noch sicherstellen, dass Sie es über POST-Anfrage senden, nicht GET. Wenn Sie es über eine GET-Anfrage senden, könnte es im Klartext in den Browser-Verlaufsprotokollen des Benutzers oder in den Zugriffsprotokollen des Webservers gespeichert werden.
Ja, das wusste ich, aber es ist immer noch ein guter Kommentar, um andere zu verlassen, die hierher kommen. :) – WhyNotHugo
Die anderen Poster sind korrekt. Nun, da Sie SSL verwenden die Übertragung des Passwort zu verschlüsseln, stellen Sie sicher, dass Sie es mit einem guten Algorithmus und Salz sind Hashing so dass es geschützt ist, wenn es in Ruhe auch ...
Ja, das merke ich, danke, ich habe mich hier nur auf die Übertragung bezogen. – WhyNotHugo
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 zur Anmeldeseite der Unternehmens-Website (https). Drücken Sie F12, klicken Sie auf die Netzwerkregisterkarte, deaktivieren Sie das persistente Protokoll, minimieren Sie die Konsole, aber lassen Sie die Webseite für die Anmeldeseite offen. Setzen Sie sich hin und essen Sie zu Mittag. Beobachten Sie, wie sich ein Mitarbeiter anmeldet, nachdem sich ein Mitarbeiter auf der Firmenwebsite angemeldet hat und ein guter kleiner Mitarbeiter sich abmeldet, wenn er fertig ist. Beenden Sie das Mittagessen, setzen Sie sich am Computer, rufen Sie den Tab "Netzwerk" auf und sehen Sie jeden Benutzernamen und jedes Passwort im Klartext im Formular bodys.
Keine speziellen Werkzeuge, keine speziellen Kenntnisse, keine fancy Hacking-Hardware, keine Keylogger nur gute alte F12.
Aber hey, denken Sie weiter alles, was Sie brauchen, ist SSL. Die bösen Jungs werden dich dafür lieben.
Ihr Cafeteria-Kommentar macht keinen Sinn, egal wie sehr ich ihn neu lese. Warum sollten die Leute einfach zu einem Computer gehen und ihre Anmeldeinformationen eingeben? Was versuchst du zu beweisen? Auch das Hashing wird diese * in keiner Weise * unsicherer machen. Es war üblich, Passwörter zu hacken und sie über Klartext-HTTP zu übertragen, als diese Frage im Jahr 2009 geschrieben wurde. – WhyNotHugo
Ich habe beide aufgestuft, weil ja die akzeptierte Antwort viele Jahre später gelesen wurde. Es wäre gut, wenn @CodeDog auf eine Minderungsstrategie hinweisen würde. Und ja, die Leute werden einfach zu zufälligen PCs gehen, zum Beispiel in der lokalen Bibliothek, und ihre Daten eingeben! – JoeAC
Ich verschlüsseln Passwörter Client-Seite mit einem öffentlichen Schlüssel, dann nur das verschlüsselte Passwort in das Formular eingeben. Es ist ein asymmetrischer Schlüssel, so dass der öffentliche Schlüssel der Client-Seite für die Angreifer nutzlos ist. Jedes Protokoll erzeugt ein neues Schlüsselpaar, so dass Wiederholungsangriffe auch nicht funktionieren. Der Schlüssel ändert sich sogar bei fehlgeschlagenen Anmeldeversuchen. Die Schlüsselpaare werden serverseitig generiert, wenn die Benutzer den Anmeldebildschirm erreichen. Nur der öffentliche Schlüssel wird dem clientseitigen Code bereitgestellt. – CodeDog
Kleiner Nitpick: einige Login-Formulare benutzen JavaScript, um das Passwort zu hashen anstatt es als reinen Text zu senden. – Thorarin
@Thorarin wenn sie es wirklich hash, das bedeutet der Server speichert das Passwort im Klartext, so dass es Hash mit dem gleichen Salz zu überprüfen. Ick! Das Senden des Passworts in SSL-umschlossenem Text ist besser, da der Server das Passwort dann nicht im Klartext speichern muss. – DGM
@DGM: Double Hashing ist auch eine Option, so dass Klartext Passwörter nicht unbedingt notwendig sind. – Thorarin