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

Nach dem Lesen dieses Abschnitts:

In einer Anmerkung unten habe ich darauf hingewiesen, dass Websites, die hauptsächlich auf ältere Menschen, geistig Behinderte oder sehr junge Menschen ausgerichtet sind, für Personen verwirrend werden können, wenn sie aufgefordert werden, eine sichere Passwort-Wiederherstellungsprozedur durchzuführen. Obwohl wir es in diesen Fällen einfach und banal finden mögen, benötigen einige Benutzer die zusätzliche Unterstützung entweder von einem technischen Dienstmitarbeiter, der ihnen beim Einloggen hilft, oder es ihnen direkt per E-Mail anzeigt.

In solchen Systemen könnte die Abwanderungsrate dieser Zielgruppen die Anwendung lahmlegen, wenn den Benutzern nicht dieses Maß an Zugriffsunterstützung gewährt wird, daher antworten Sie bitte mit einem solchen Setup im Hinterkopf.

Ich frage mich, ob eine dieser Anforderungen ein abrufbares Passwortsystem vorschreibt. Zum Beispiel ruft Tante Mabel an und sagt: "Ihr Internetprogramm funktioniert nicht, ich kenne mein Passwort nicht". "OK", sagt der Kundenservicemitarbeiter, "lassen Sie mich ein paar Details überprüfen und dann werde ich Ihnen ein neues Passwort geben. Wenn Sie sich das nächste Mal einloggen, wird es Sie fragen, ob Sie dieses Passwort behalten oder es in etwas ändern möchten, das Sie sich leichter merken können."

Dann ist das System so eingerichtet, dass es weiß, wann ein Passwort zurückgesetzt wurde, und eine Meldung "Möchten Sie das neue Passwort behalten oder ein neues wählen?" anzeigt.

Ist das schlimmer für die weniger PC-erfahrenen Benutzer als wenn ihnen ihr altes Passwort genannt würde? Und während der Kundenservice-Mitarbeiter Unfug treiben kann, ist die Datenbank selbst viel sicherer, falls sie kompromittiert wird.

Kommentieren Sie, was an meinem Vorschlag schlecht ist, und ich werde eine Lösung vorschlagen, die tatsächlich das tut, was Sie ursprünglich wollten.

Answer 2

Michael Brooks war ziemlich laut über CWE-257 - die Tatsache, dass unabhängig von der verwendeten Methode Sie (der Administrator) das Passwort immer noch wiederherstellen können. Also, wie wäre es mit diesen Optionen:

1. Verschlüsseln Sie das Passwort mit dem öffentlichen Schlüssel einer anderen Person - einer externen Autorität. Auf diese Weise können Sie es persönlich nicht rekonstruieren, und der Benutzer muss zur externen Autorität gehen und um die Wiederherstellung seines Passworts bitten.
2. Verschlüsseln Sie das Passwort mit einem Schlüssel, der aus einer zweiten Passphrase generiert wurde. Führen Sie diese Verschlüsselung clientseitig durch und übermitteln Sie sie niemals im Klartext an den Server. Zur Wiederherstellung führen Sie die Entschlüsselung erneut clientseitig durch, indem Sie den Schlüssel aus ihrer Eingabe neu generieren. Zugegebenermaßen handelt es sich bei diesem Ansatz im Grunde um die Verwendung eines zweiten Passworts, aber Sie können sie immer daran erinnern, es aufzuschreiben oder den alten Sicherheitsfrage-Ansatz zu verwenden.

Ich denke, 1. ist die bessere Wahl, weil es Ihnen ermöglicht, jemanden innerhalb des Unternehmens des Kunden zu benennen, der den privaten Schlüssel hält. Stellen Sie sicher, dass sie den Schlüssel selbst generieren und ihn mit Anweisungen in einem Safe usw. aufbewahren. Sie könnten sogar die Sicherheit erhöhen, indem Sie sich dafür entscheiden, nur bestimmte Zeichen aus dem Passwort zu verschlüsseln und an die interne dritte Partei weiterzugeben, damit sie das Passwort knacken müssen, um es zu erraten. Wenn Sie diese Zeichen dem Benutzer zur Verfügung stellen, werden sie sich wahrscheinlich daran erinnern, was es war!

Answer 3

Es gab viel Diskussion über Sicherheitsbedenken für den Benutzer als Antwort auf diese Frage, aber ich möchte auch Vorteile erwähnen. Bisher habe ich keinen legitimen Vorteil gesehen, der genannt wurde, um ein wiederherstellbares Passwort im System zu speichern. Bedenke dies:

• Profitiert der Benutzer davon, sein Passwort per E-Mail zu erhalten? Nein. Sie erhalten mehr Nutzen von einem einmaligen Passwortrücksetzungslink, mit dem sie hoffentlich ein Passwort wählen können, das sie sich erinnern werden.
• Profitiert der Benutzer davon, dass sein Passwort auf dem Bildschirm angezeigt wird? Nein, aus dem gleichen Grund wie oben; sie sollten ein neues Passwort wählen.
• Profitiert der Benutzer davon, dass ein Supportmitarbeiter das Passwort dem Benutzer mitteilt? Nein; wieder, wenn der Supportmitarbeiter die Anfrage des Benutzers nach ihrem Passwort als ordnungsgemäß authentifiziert betrachtet, ist es für den Benutzer vorteilhafter, ein neues Passwort zu erhalten und die Möglichkeit zu haben, es zu ändern. Außerdem ist der telefonische Support kostspieliger als automatische Passwortrücksetzungen, sodass das Unternehmen auch keinen Nutzen hat.

Es scheint, dass die einzigen, die von wiederherstellbaren Passwörtern profitieren können, diejenigen mit böswilliger Absicht oder Befürworter von schlechten APIs sind, die einen Passwortaustausch über Dritte erfordern (bitte verwenden Sie niemals solche APIs!). Vielleicht können Sie Ihr Argument gewinnen, indem Sie Ihren Kunden wahrheitsgemäß mitteilen, dass das Unternehmen keine Vorteile hat und nur Haftungsrisiken durch das Speichern von wiederherstellbaren Passwörtern hat.

Wenn Sie zwischen den Zeilen dieser Arten von Anfragen lesen, werden Sie feststellen, dass Ihre Kunden wahrscheinlich gar nicht verstehen oder sich tatsächlich darum kümmern, wie Passwörter verwaltet werden. Was sie wirklich wollen, ist ein Authentifizierungssystem, das für ihre Benutzer nicht so schwer ist. Zusätzlich zu der Aussage, dass sie tatsächlich keine wiederherstellbaren Passwörter wollen, sollten Sie ihnen Möglichkeiten bieten, den Authentifizierungsprozess weniger schmerzhaft zu gestalten, insbesondere wenn Sie nicht die hohen Sicherheitsstufen eines, sagen wir, einer Bank benötigen:

• Ermöglichen Sie es dem Benutzer, ihre E-Mail-Adresse als Benutzernamen zu verwenden. Ich habe unzählige Fälle gesehen, in denen der Benutzer seinen Benutzernamen vergisst, aber nur wenige ihre E-Mail-Adresse vergessen.
• Bieten Sie OpenID an und lassen Sie einen Dritten die Kosten für Benutzer vergesslichkeit tragen.
• Lockern Sie die Passwortbeschränkungen. Ich bin sicher, wir waren alle unglaublich genervt, als eine Webseite Ihr bevorzugtes Passwort nicht zulässt, aufgrund nutzloser Anforderungen wie "Sie können keine Sonderzeichen verwenden" oder "Ihr Passwort ist zu lang" oder "Ihr Passwort muss mit einem Buchstaben beginnen." Außerdem, wenn Benutzerfreundlichkeit ein größeres Anliegen ist als die Passwortstärke, könnten Sie sogar die nicht-blöden Anforderungen lockern, indem Sie kürzere Passwörter zulassen oder keine Mischung aus Zeichenklassen erfordern. Mit gelockerten Beschränkungen werden Benutzer eher ein Passwort verwenden, das sie nicht vergessen werden.
• Lassen Sie Passwörter nicht ablaufen.
• Ermöglichen Sie es dem Benutzer, ein altes Passwort wiederzuverwenden.
• Erlauben Sie es dem Benutzer, seine eigene Passwortrücksetzfrage zu wählen.

Aber wenn Sie, aus irgendeinem Grund (und bitte teilen Sie uns den Grund mit), wirklich, wirklich, wirklich die Möglichkeit haben müssen, ein wiederherstellbares Passwort zu haben, könnten Sie den Benutzer davor schützen, seine anderen Online-Konten potenziell zu gefährden, indem Sie ihm ein authentifizierungssystem ohne Passwortbasis bieten. Da die Menschen bereits mit Benutzername/Passwort-Systemen vertraut sind und dies eine gut erprobte Lösung ist, wäre dies eine letzte Möglichkeit, aber es gibt sicherlich viele kreative Alternativen zu Passwörtern:

• Lassen Sie den Benutzer eine numerische PIN wählen, bevorzugt nicht 4-stellig, und am besten nur, wenn Brute-Force-Versuche geschützt sind.
• Lassen Sie den Benutzer eine Frage mit einer kurzen Antwort wählen, die nur sie kennen, sich nie ändert, sich immer erinnern und keinen anderen Personen mitteilen möchten.
• Lassen Sie den Benutzer einen Benutzernamen eingeben und zeichnen Sie dann eine leicht zu merkende Form mit ausreichenden Permutationen, um sich gegen das Raten zu schützen (siehe dieses schicke Foto darüber, wie das G1 dies zum Entsperren des Telefons macht).
• Für eine Kinderwebsite könnten Sie ein nebulöses Kreatur basierend auf dem Benutzernamen automatisch generieren (ähnlich wie ein Identicon) und den Benutzer bitten, der Kreatur einen geheimen Namen zu geben. Sie können dann aufgefordert werden, den geheimen Namen der Kreatur einzugeben, um sich anzumelden.

Answer 4

Wie wäre es mit einem Zwischenlager?

Speichern Sie die Passwörter mit einer starken Verschlüsselung und ermöglichen Sie keine Zurücksetzungen.

Anstatt Passwörter zurückzusetzen, erlauben Sie das Senden eines Einmalpassworts (das beim ersten Einloggen geändert werden muss). Lassen Sie den Benutzer dann das Passwort ändern, wie sie möchten (das vorherige, wenn sie wollen).

Sie können dies als sicheren Mechanismus zum Zurücksetzen von Passwörtern "verkaufen".

Answer 5

Der einzige Weg, einem Benutzer zu ermöglichen, sein ursprüngliches Passwort abzurufen, besteht darin, es mit dem eigenen öffentlichen Schlüssel des Benutzers zu verschlüsseln. Nur dieser Benutzer kann dann sein Passwort entschlüsseln.

Die Schritte wären also:

1. Benutzer registriert sich auf Ihrer Website (natürlich über SSL) ohne ein Passwort festzulegen. Melden Sie sie automatisch an oder stellen Sie ein temporäres Passwort zur Verfügung.
2. Sie bieten an, ihren öffentlichen PGP-Schlüssel für die zukünftige Passwortwiederherstellung zu speichern.
3. Sie laden ihren öffentlichen PGP-Schlüssel hoch.
4. Sie werden gebeten, ein neues Passwort festzulegen.
5. Sie übermitteln ihr Passwort.
6. Sie hashen das Passwort mit dem besten verfügbaren Passworthash-Algorithmus (z.B. bcrypt). Verwenden Sie dies beim Validieren des nächsten Logins.
7. Sie verschlüsseln das Passwort mit dem öffentlichen Schlüssel und speichern es separat.

Sollte der Benutzer dann nach seinem Passwort fragen, antworten Sie mit dem verschlüsselten (nicht gehashten) Passwort. Wenn der Benutzer in Zukunft nicht in der Lage sein möchte, sein Passwort abzurufen (er könnte es nur auf ein vom Dienst generiertes zurücksetzen), können die Schritte 3 und 7 übersprungen werden.