Wie sollte ich ethisch den Umgang mit der Speicherung von Benutzerpasswörtern für spätere Klartextabfragen angehen?

Question

Während ich weiterhin mehr und mehr Websites und Webanwendungen baue, werde ich oft gebeten, Benutzerpasswörter so zu speichern, dass sie im Falle eines Problems abgerufen werden können (entweder um einen vergessenen Passwort-Link per E-Mail zu senden oder sie telefonisch durchzuführen). Wenn ich kann, kämpfe ich heftig gegen diese Praxis und programmiere 'zusätzlich', um Passwortrücksetzungen und administrative Unterstützung möglich zu machen, ohne ihr tatsächliches Passwort zu speichern.

Wenn ich nicht dagegen kämpfen kann (oder nicht gewinnen kann), verschlüssele ich das Passwort immer auf irgendeine Weise, so dass es zumindest nicht als Klartext in der Datenbank gespeichert wird. Obwohl ich mir bewusst bin, dass es nicht viel brauchen würde, wenn mein DB gehackt wird, damit der Täter die Passwörter knacken kann, deshalb fühle ich mich unwohl dabei.

In einer perfekten Welt würden die Leute ihre Passwörter häufig aktualisieren und sie nicht auf vielen verschiedenen Websites duplizieren - leider kenne ich VIELE Leute, die dasselbe Arbeits-/Heim-/E-Mail-/Bankpasswort haben und es mir sogar freiwillig geben, wenn sie Hilfe benötigen. Ich möchte nicht dafür verantwortlich sein, dass sie finanziell zugrunde gehen, wenn meine DB-Sicherheitsverfahren aus irgendeinem Grund versagen.

Moralisch und ethisch fühle ich mich dafür verantwortlich, das zu schützen, was für einige Benutzer ihre Existenzgrundlage sein kann, auch wenn sie es mit viel weniger Respekt behandeln. Ich bin mir sicher, dass es viele Möglichkeiten gibt, sich den Salzhaschen und verschiedenen Codierungsoptionen zu nähern und Argumente dafür anzuführen, aber gibt es eine einzige 'beste Praxis', wenn man sie speichern muss? In fast allen Fällen verwende ich PHP und MySQL, wenn das einen Unterschied in der Handhabung der Details macht.

Zusätzliche Informationen für das Kopfgeld

I want to clarify that I know this is not something you want to have to do and that in most cases refusal to do so is best. I am, however, not looking for a lecture on the merits of taking this approach I am looking for the best steps to take if you do take this approach.

In a note below I made the point that websites geared largely toward the elderly, mentally challenged, or very young can become confusing for people when they are asked to perform a secure password recovery routine. Though we may find it simple and mundane in those cases some users need the extra assistance of either having a service tech help them into the system or having it emailed/displayed directly to them.

In such systems the attrition rate from these demographics could hobble the application if users were not given this level of access assistance, so please answer with such a setup in mind.

Thanks to Everyone

This has been a fun question with lots of debate and I have enjoyed it. In the end I selected an answer that both retains password security (I will not have to keep plain text or recoverable passwords), but also makes it possible for the user base I specified to log into a system without the major drawbacks I have found from normal password recovery.

As always there were about 5 answers that I would like to have marked as correct for different reasons, but I had to choose the best one--all the rest got a +1. Thanks everyone!

Also, thanks to everyone in the Stack community who voted for this question and/or marked it as a favorite. I take hitting 100 up votes as a compliment and hope that this discussion has helped someone else with the same concern that I had.

Answer 1

Von dem Wenigen, was ich zu diesem Thema verstehe, glaube ich, dass, wenn Sie eine Website mit einer Anmeldung/Passwort erstellen, Sie das Klartextpasswort überhaupt nicht auf Ihrem Server sehen sollten. Das Passwort sollte gehasht und wahrscheinlich gesalzen werden, bevor es überhaupt den Client verlässt.

Wenn Sie das Klartextpasswort nie sehen, stellt sich die Frage der Wiederherstellung nicht.

Außerdem habe ich (aus dem Web) erfahren, dass (angeblich) einige Algorithmen wie MD5 nicht mehr als sicher gelten. Ich habe keine Möglichkeit, das selbst zu beurteilen, aber es ist etwas zu berücksichtigen.

Answer 2

Benötigen die Benutzer wirklich die Wiederherstellung (z. B. Mitteilung), was das vergessene Passwort war, oder müssen sie einfach nur Zugang zum System erhalten? Wenn sie wirklich ein Passwort zum Einloggen möchten, warum nicht eine Routine haben, die einfach das alte Passwort (was auch immer es ist) in ein neues Passwort ändert, das die Support-Person der Person geben kann, die ihr Passwort verloren hat?

Ich habe mit Systemen gearbeitet, die genau das tun. Die Support-Person hat keine Möglichkeit zu wissen, was das aktuelle Passwort ist, kann es aber auf einen neuen Wert zurücksetzen. Natürlich sollten alle solchen Zurücksetzungen irgendwo protokolliert werden und es wäre ratsam, eine E-Mail an den Benutzer zu generieren, in der steht, dass das Passwort zurückgesetzt wurde.

Eine weitere Möglichkeit ist, zwei gleichzeitige Passwörter zuzulassen, die den Zugriff auf ein Konto ermöglichen. Eines ist das "normale" Passwort, das der Benutzer verwaltet, und das andere ist wie ein Skelett/Hauptschlüssel, der nur von dem Support-Personal bekannt ist und für alle Benutzer gleich ist. Auf diese Weise kann der Support-Mitarbeiter, wenn ein Benutzer ein Problem hat, sich mit dem Hauptschlüssel beim Konto anmelden und dem Benutzer helfen, sein Passwort zu ändern. Selbstverständlich sollten alle Anmeldungen mit dem Hauptschlüssel ebenfalls vom System protokolliert werden. Als zusätzliche Maßnahme könnten Sie auch die Zugriffsberechtigungen des Support-Personals überprüfen, wenn der Hauptschlüssel verwendet wird.

-EDIT- Als Antwort auf die Kommentare zum Thema "keinen Hauptschlüssel haben": Ich stimme zu, dass es genauso schlecht ist, wie ich glaube, dass es schlecht ist, dass jemand anderes als der Benutzer Zugriff auf das Benutzerkonto hat. Wenn Sie sich die Frage anschauen, basiert die gesamte Prämisse darauf, dass der Kunde eine stark kompromittierte Sicherheitsumgebung vorschreibt.

Ein Hauptschlüssel muss nicht so schlimm sein, wie es zunächst scheint. Ich habe früher in einem Verteidigungsbetrieb gearbeitet, wo sie die Notwendigkeit sahen, dass der Mainframe-Computerbetreiber zu bestimmten Gelegenheiten "besonderen Zugriff" haben musste. Sie legten einfach das spezielle Passwort in einen versiegelten Umschlag und klebten ihn an den Schreibtisch des Betreibers. Um das Passwort zu verwenden (das der Betreiber nicht kannte), musste er den Umschlag öffnen. Bei jedem Schichtwechsel war es die Aufgabe des Schichtleiters zu prüfen, ob der Umschlag geöffnet worden war, und wenn ja, das Passwort sofort ändern zu lassen (durch eine andere Abteilung) und das neue Passwort in einen neuen Umschlag zu stecken und den Prozess von vorne zu beginnen. Der Betreiber wurde befragt, warum er ihn geöffnet hatte, und der Vorfall wurde für die Akten dokumentiert.

Obwohl dies kein Verfahren ist, das ich entwerfen würde, funktionierte es und sorgte für eine ausgezeichnete Verantwortlichkeit. Alles wurde protokolliert und überprüft, außerdem hatten alle Betreiber DOD-Ermächtigungen und es gab keine Missbräuche.

Aufgrund der Überprüfung und Aufsicht wussten alle Betreiber, dass sie bei missbräuchlicher Verwendung des geöffneten Umschlags sofort entlassen und möglicherweise strafrechtlich verfolgt wurden.

Also glaube ich, die eigentliche Antwort ist, wenn man die Dinge richtig machen möchte, sollte man Leute einstellen, denen man vertrauen kann, Hintergrundüberprüfungen durchführen und angemessene Managementaufsicht und Verantwortlichkeit ausüben.

Aber dann wiederum, wenn dieser arme Kerl gute Manager hätte, würden sie ja nicht nach einer so kompromittierten Sicherheitslösung gefragt haben, oder?

Answer 3

Salz- und hashe das Passwort des Benutzers wie gewohnt. Beim Einloggen des Benutzers erlaube sowohl das Passwort des Benutzers (nach dem Salzen/Hashen), als auch was der Benutzer wörtlich eingegeben hat, übereinzustimmen.

Dies ermöglicht es dem Benutzer, sein geheimes Passwort einzugeben, erlaubt es ihnen aber auch, die gesalzene/gehashte Version ihres Passworts einzugeben, was jemand aus der Datenbank lesen würde.

Im Grunde genommen soll das gesalzene/gehashte Passwort auch ein "Klartext"-Passwort sein.

Answer 4

Eine weitere Option, die Sie vielleicht nicht in Betracht gezogen haben, ist die Möglichkeit, Aktionen per E-Mail zu ermöglichen. Es ist etwas umständlich, aber ich habe dies für einen Kunden implementiert, der wollte, dass Benutzer "außerhalb" ihres Systems bestimmte Teile des Systems nur anzeigen können. Zum Beispiel:

1. Sobald sich ein Benutzer registriert hat, hat er vollen Zugriff (wie auf einer normalen Website). Die Registrierung muss eine E-Mail enthalten.
2. Wenn Daten oder eine Aktion benötigt werden und der Benutzer sich nicht an sein Passwort erinnert, kann er die Aktion trotzdem durch Klicken auf eine spezielle "E-Mail für Berechtigung senden" Schaltfläche ausführen, die direkt neben der regulären "Senden" Schaltfläche liegt.
3. Die Anfrage wird dann an die E-Mail gesendet, mit einem Hyperlink, der fragt, ob die Aktion durchgeführt werden soll. Dies ist ähnlich wie ein Link in einer E-Mail zum Zurücksetzen des Passworts, aber anstelle des Zurücksetzens des Passworts wird die Einmalaktion ausgeführt.
4. Der Benutzer klickt dann auf "Ja" und bestätigt, dass die Daten angezeigt werden sollen oder die Aktion durchgeführt werden soll, Daten offengelegt werden usw.

Wie Sie in den Kommentaren erwähnt haben, funktioniert dies nicht, wenn die E-Mail kompromittiert ist, aber es geht auf den Kommentar von @joachim ein, der nicht das Passwort zurücksetzen möchte. Irgendwann müssten sie das Passwort zurücksetzen, aber sie könnten dies zu einem günstigeren Zeitpunkt tun oder mit Unterstützung eines Administrators oder eines Freundes, wenn nötig.

Eine Variante dieser Lösung wäre die Übermittlung der Aktionsanfrage an einen vertrauenswürdigen Administrator einer dritten Partei. Dies würde am besten bei älteren Personen, geistig behinderten, sehr jungen oder anderweitig verwirrten Benutzern funktionieren. Natürlich erfordert dies einen vertrauenswürdigen Administrator, der diesen Personen bei ihren Aktionen zur Seite steht.

Answer 5

Öffnen Sie eine DB auf einem eigenständigen Server und geben Sie jeder Webserver, der diese Funktion benötigt, eine verschlüsselte Remoteverbindung.
Es muss keine relationale DB sein, es kann auch ein Dateisystem mit FTP-Zugriff sein, das Ordner und Dateien anstelle von Tabellen und Zeilen verwendet.
Geben Sie den Webservern bei Bedarf Schreibberechtigungen.

Speichern Sie die nicht abrufbare Verschlüsselung des Passworts in der DB der Website (nennen wir sie "pass-a") wie normale Menschen das tun :)
Speichern Sie bei jedem neuen Benutzer (oder Passwortänderung) eine einfache Kopie des Passworts in der entfernten DB. Verwenden Sie die ID des Servers, die ID des Benutzers und "pass-a" als zusammengesetzten Schlüssel für dieses Passwort. Sie können sogar eine bidirektionale Verschlüsselung des Passworts verwenden, um ruhiger zu schlafen.

Jetzt muss jemand sowohl das Passwort als auch seinen Kontext (Website-ID + Benutzer-ID + "pass-a") erhalten:

1. Hacken Sie die DB der Website, um ein ("pass-a", Benutzer-ID)-Paar oder Paare zu erhalten.
2. Holen Sie sich die ID der Website aus einer Konfigurationsdatei
3. Finden Sie und hacken Sie sich in die entfernte Passwort-DB ein.

Sie können die Zugänglichkeit des Passwort-Abrufdienstes kontrollieren (stellen Sie ihn nur als gesicherten Webdienst zur Verfügung, erlauben Sie nur eine bestimmte Anzahl von Abrufen pro Tag, machen Sie es manuell usw.) und sogar zusätzliche Kosten für diese "spezielle Sicherheitsvereinbarung" erheben.
Der Passwort-Abruf-DB-Server ist ziemlich versteckt, da er nicht viele Funktionen erfüllt und besser gesichert werden kann (Sie können Berechtigungen, Prozesse und Dienste eng anpassen).

Alles in allem machen Sie die Arbeit für den Hacker schwieriger. Die Wahrscheinlichkeit eines Sicherheitsverstoßes auf einem einzelnen Server bleibt gleich, aber es wird schwierig sein, sinnvolle Daten (eine Übereinstimmung von Konto und Passwort) zusammenzustellen.