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

Bin gerade auf diese interessante und hitzige Diskussion gestoßen. Was mich jedoch am meisten überraschte, war, wie wenig Aufmerksamkeit der folgenden grundlegenden Frage geschenkt wurde:

• Q1. Was sind die tatsächlichen Gründe, warum der Benutzer darauf besteht, Zugang zu im Klartext gespeicherten Passwörtern zu haben? Warum ist dies von so großem Wert?

Die Information, ob Benutzer älter oder jünger sind, beantwortet diese Frage nicht wirklich. Aber wie kann eine Geschäftsentscheidung getroffen werden, ohne das Anliegen des Kunden richtig zu verstehen?

Warum ist das wichtig? Denn wenn der eigentliche Grund für die Anfragen der Kunden das System ist, das schmerzhaft schwierig zu benutzen ist, könnte das Ansprechen genau dieses Grundes vielleicht das eigentliche Problem lösen?

Da ich diese Information nicht habe und nicht mit diesen Kunden sprechen kann, kann ich nur vermuten: Es geht um Benutzerfreundlichkeit, siehe oben.

Eine weitere Frage, die gestellt wurde:

• Q2. Wenn der Benutzer sich das Passwort erst gar nicht merken kann, warum ist dann das alte Passwort wichtig?

Und hier ist eine mögliche Antwort. Wenn du eine Katze namens "MiauMiau" hast und ihren Namen als Passwort benutzt hast, aber vergessen hast, dass du es getan hast, würdest du lieber daran erinnert werden, was es war, oder würdest du lieber etwas wie "#zy*RW(ew" zugesandt bekommen?

Ein weiterer möglicher Grund ist, dass der Benutzer es als mühsame Arbeit empfindet, ein neues Passwort zu erstellen! Daher gibt ihm das Zurückschicken des alten Passworts die Illusion, ihn vor dieser schmerzhaften Arbeit zu bewahren.

Ich versuche nur den Grund zu verstehen. Aber egal was der Grund ist, es ist der Grund, nicht die Ursache, die angegangen werden muss.

Als Benutzer möchte ich, dass die Dinge einfach sind! Ich möchte nicht hart arbeiten!

Wenn ich mich auf einer Nachrichtenseite anmelde, um Zeitungen zu lesen, möchte ich 1111 als Passwort eingeben und durch sein!!!

Ich weiß, dass es unsicher ist, aber was kümmert es mich, ob jemand Zugriff auf mein "Konto" bekommt? Ja, er kann auch die Nachrichten lesen!

Speichert die Seite meine "privaten" Informationen? Die Nachrichten, die ich heute gelesen habe? Dann ist es das Problem der Seite, nicht meines! Zeigt die Seite private Informationen an authentifizierte Nutzer? Dann zeige es erst gar nicht!

Dies soll nur die Einstellung des Benutzers zu dem Problem verdeutlichen.

Zusammenfassend glaube ich nicht, dass das Problem darin besteht, wie man im Klartext Passwörter "sicher" speichert (was wir wissen, ist unmöglich), sondern vielmehr darin, wie man sich mit den eigentlichen Anliegen der Kunden auseinandersetzt.

Answer 2

Es tut mir leid, aber solange du einen Weg hast, ihr Passwort zu entschlüsseln, gibt es keine Möglichkeit, dass es sicher ist. Bekämpfe es verbissen und wenn du verlierst, CYA.

Answer 3

Umgang mit verlorenen/vergessenen Passwörtern:

Niemand sollte in der Lage sein, Passwörter wiederherzustellen.

Wenn Benutzer ihre Passwörter vergessen haben, müssen sie zumindest ihre Benutzernamen oder E-Mail-Adressen kennen. Auf Anfrage wird in der Benutzertabelle eine GUID generiert und eine E-Mail mit einem Link, der die GUID als Parameter enthält, an die E-Mail-Adresse des Benutzers gesendet.

Die Seite hinter dem Link überprüft, ob der Parameter GUID wirklich existiert (wahrscheinlich mit einiger Timeout-Logik) und fordert den Benutzer auf, ein neues Passwort einzugeben.

Wenn Sie eine Hotline für Benutzer benötigen, fügen Sie einige Rollen zu Ihrem Berechtigungsmodell hinzu und ermöglichen Sie der Hotline-Rolle, sich vorübergehend als identifizierter Benutzer einzuloggen. Protokollieren Sie alle solchen Hotline-Logins. Zum Beispiel bietet Bugzilla eine solche Impersonation-Funktion für Admins an.

Answer 4

Was ist mit dem Versenden des Klartextpassworts bei der Registrierung per E-Mail, bevor es verschlüsselt und verloren geht? Ich habe viele Websites gesehen, die das machen, und das Passwort vom Benutzer per E-Mail zu erhalten ist sicherer als es auf Ihrem Server/Computer herumliegen zu lassen.

Answer 5

Wenn Sie die Anforderung zur Speicherung wiederherstellbarer Passwörter nicht einfach ablehnen können, wie wäre es mit diesem Gegenargument.

Entweder hashen wir Passwörter ordnungsgemäß und bauen einen Rücksetzmechanismus für die Benutzer auf, oder wir entfernen alle persönlich identifizierbaren Informationen aus dem System. Sie können eine E-Mail-Adresse verwenden, um Benutzervorlieben einzurichten, aber das war's auch schon. Verwenden Sie ein Cookie, um Vorlieben automatisch bei zukünftigen Besuchen abzurufen und die Daten nach einer angemessenen Zeit zu löschen.

Die Möglichkeit, die bei Passwortrichtlinien oft übersehen wird, ist, ob überhaupt ein Passwort erforderlich ist. Wenn Ihre Passwortrichtlinie nur Anrufe beim Kundenservice verursacht, könnten Sie es vielleicht auch einfach abschaffen.