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

Wie wäre es, einen anderen Ansatz oder Blickwinkel auf dieses Problem zu verfolgen? Fragen Sie, warum das Passwort im Klartext vorliegen muss: Wenn es darum geht, dass der Benutzer das Passwort abrufen kann, dann brauchen Sie streng genommen das von ihnen festgelegte Passwort nicht abzurufen (sie erinnern sich sowieso nicht daran), sondern Sie müssen ihnen ein Passwort geben, das sie verwenden können.

Denken Sie darüber nach: Wenn der Benutzer das Passwort abrufen muss, dann, weil sie es vergessen haben. In diesem Fall ist ein neues Passwort genauso gut wie das alte. Einer der Nachteile der heute verwendeten gängigen Mechanismen zum Zurücksetzen von Passwörtern besteht jedoch darin, dass die bei einem Reset erzeugten Passwörter im Allgemeinen eine Reihe von zufälligen Zeichen sind, sodass sie für den Benutzer schwierig sind, einfach korrekt einzugeben, es sei denn, sie kopieren und einfügen. Das kann ein Problem für weniger versierte Computerbenutzer sein.

Ein Weg um dieses Problem zu umgehen, besteht darin, auto-generierte Passwörter bereitzustellen, die eher natürlicher Text sind. Natürlichsprachige Zeichenfolgen haben zwar nicht die Entropie, die eine Zeichenfolge von zufälligen Zeichen derselben Länge hat, aber nichts sagt, dass Ihr auto-generiertes Passwort nur 8 (oder 10 oder 12) Zeichen haben muss. Erhalten Sie eine Passphrase mit hoher Entropie durch Verknüpfen mehrerer zufälliger Wörter (lassen Sie einen Zwischenraum zwischen ihnen, damit sie immer noch von jedem, der lesen kann, erkannt und eingegeben werden können). Sechs zufällige Wörter unterschiedlicher Länge sind wahrscheinlich einfacher korrekt und selbstbewusst einzugeben als 10 zufällige Zeichen und können auch eine höhere Entropie haben. Z. B. hätte die Entropie eines 10 Zeichen langen Passworts, das zufällig aus Großbuchstaben, Kleinbuchstaben, Ziffern und 10 Satzzeichen ausgewählt wurde (insgesamt 72 gültige Symbole), eine Entropie von 61,7 Bits. Wenn Sie ein Wörterbuch von 7776 Wörtern (wie Diceware verwendet) verwenden, das für eine sechswortige Passphrase zufällig ausgewählt werden könnte, hätte die Passphrase eine Entropie von 77,4 Bits. Weitere Informationen finden Sie in den Diceware FAQ.

• eine Passphrase mit etwa 77 Bits Entropie: "admit prose flare table acute flair"

• ein Passwort mit etwa 74 Bits Entropie: "K:&$R^tt~qkD"

Ich würde es bevorzugen, den Satz einzugeben, und mit kopieren und einfügen ist der Satz genauso einfach zu verwenden wie das Passwort, also kein Verlust. Natürlich, wenn Ihre Website (oder was auch immer das geschützte Gut ist) keine 77 Bits Entropie für eine auto-generierte Passphrase benötigt, generieren Sie weniger Wörter (was ich sicher bin, dass Ihre Benutzer zu schätzen wüssten).

Ich verstehe die Argumente, dass es passwortgeschützte Güter gibt, die wirklich keinen hohen Wert haben, sodass der Bruch eines Passworts nicht das Ende der Welt sein könnte. Zum Beispiel würde es mich wahrscheinlich nicht stören, wenn 80% der Passwörter, die ich auf verschiedenen Websites verwende, gehackt würden: Alles, was passieren könnte, ist, dass jemand eine Weile Spam sendet oder unter meinem Namen postet. Das wäre nicht großartig, aber es ist nicht so, als würden sie in mein Bankkonto einbrechen. Angesichts der Tatsache jedoch, dass viele Menschen dasselbe Passwort für ihre Webforum-Websites verwenden wie für ihre Bankkonten (und wahrscheinlich nationale Sicherheitsdatenbanken), denke ich, dass es am besten wäre, auch diese 'niedrigwertigen' Passwörter als nicht wiederherstellbar behandeln.

Answer 2

Stellen Sie sich vor, jemand hat den Bau eines großen Gebäudes in Auftrag gegeben - einer Bar, sagen wir - und folgendes Gespräch findet statt:

Architekt: Für ein Gebäude dieser Größe und Kapazität benötigen Sie hier, hier und hier Notausgänge.
Kunde: Nein, das ist zu kompliziert und teuer in der Unterhaltung, ich möchte keine Seitentüren oder Hintertüren.
Architekt: Herr, Notausgänge sind keine Option, sie sind gemäß der Brandschutzverordnung der Stadt erforderlich.
Kunde: Ich bezahle Sie nicht, um zu streiten. Tun Sie einfach, was ich gefragt habe.

Fragt der Architekt dann, wie man ethisch dieses Gebäude ohne Notausgänge bauen kann?

In der Bau- und Ingenieurbranche endet das Gespräch höchstwahrscheinlich so:

Architekt: Dieses Gebäude kann nicht ohne Notausgänge gebaut werden. Sie können zu einem anderen lizenzierten Fachmann gehen und er wird Ihnen dasselbe sagen. Ich gehe jetzt; rufen Sie mich zurück, wenn Sie bereit sind, zusammenzuarbeiten.

Computerprogrammierung ist möglicherweise kein lizenzierter Beruf, aber oft fragen sich die Leute, warum unser Beruf nicht den gleichen Respekt genießt wie ein Bau- oder Maschinenbauingenieur - nun, hier ist die Antwort. Diese Berufe, wenn sie Müll (oder sogar gefährliche) Anforderungen erhalten, werden einfach ablehnen. Sie wissen, dass es keine Entschuldigung ist zu sagen, "nun ja, ich habe mein Bestes getan, aber er hat darauf bestanden, und ich muss tun, was er sagt." Sie könnten wegen dieser Ausrede ihre Lizenz verlieren.

Ich weiß nicht, ob Sie oder Ihre Kunden Teil eines an der Börse gehandelten Unternehmens sind, aber das Speichern von Passwörtern in irgendeiner wiederherstellbaren Form würde dazu führen, dass Sie bei mehreren verschiedenen Arten von Sicherheitsprüfungen durchfallen. Das Problem ist nicht, wie schwer es für einige "Hacker" wäre, der Zugriff auf Ihre Datenbank hat, die Passwörter wiederherzustellen. Die überwiegende Mehrheit der Sicherheitsbedrohungen sind intern. Woran Sie sich schützen müssen, ist, dass sich ein verärgerter Mitarbeiter mit allen Passwörtern davonschleicht und sie an den Meistbietenden verkauft. Die Verwendung von asymmetrischer Verschlüsselung und das Speichern des privaten Schlüssels in einer separaten Datenbank verhindert dieses Szenario absolut nicht; es wird immer jemand Zugriff auf die private Datenbank haben, und das ist ein ernsthaftes Sicherheitsrisiko.

Es gibt keine ethische oder verantwortungsbewusste Möglichkeit, Passwörter in wiederherstellbarer Form zu speichern. Punkt.

Answer 3

Sie könnten das Passwort + ein Salz mit einem öffentlichen Schlüssel verschlüsseln. Für Anmeldungen prüfen Sie einfach, ob der gespeicherte Wert dem aus der Benutzereingabe + Salz berechneten Wert entspricht. Wenn es an der Zeit ist, das Passwort in Klartext wiederherzustellen, können Sie manuell oder halbautomatisch mit dem privaten Schlüssel entschlüsseln. Der private Schlüssel kann woanders gespeichert und zusätzlich symmetrisch verschlüsselt sein (dies erfordert dann eine menschliche Interaktion, um das Passwort zu entschlüsseln).

Ich denke, das ist tatsächlich ähnlich wie die Funktionsweise des Windows-Wiederherstellungsagenten funktioniert.

• Passwörter werden verschlüsselt gespeichert
• Benutzer können sich ohne Entschlüsselung in Klartext anmelden
• Passwörter können in Klartext wiederhergestellt werden, aber nur mit einem privaten Schlüssel, der außerhalb des Systems gespeichert werden kann (zum Beispiel in einem Banksafe).

Answer 4

Gib nicht auf. Die Waffe, die du benutzen kannst, um deine Kunden zu überzeugen, ist die Nicht-Abstreitbarkeit. Wenn du Benutzerpasswörter über einen Mechanismus rekonstruieren kannst, hast du ihren Kunden einen rechtlichen Nicht-Abstreitbarkeitsmechanismus gegeben und sie können jede Transaktion abstreiten, die von diesem Passwort abhängt, weil der Lieferant nicht beweisen kann, dass sie das Passwort nicht rekonstruiert und die Transaktion selbst durchgeführt haben. Wenn Passwörter korrekt als Digests anstelle von Klartext gespeichert werden, ist dies unmöglich, ergo hat entweder der Endkunde die Transaktion selbst durchgeführt oder seine Sorgfaltspflicht gegenüber dem Passwort verletzt. In beiden Fällen liegt die Haftung eindeutig bei ihm. Ich habe an Fällen gearbeitet, bei denen es um Hunderte von Millionen Dollar ging. Nichts, was du falsch machen willst.

Answer 5

Sie können Passwörter nicht ethisch speichern, um sie später im Klartext abzurufen. So einfach ist das. Selbst Jon Skeet kann Passwörter nicht ethisch speichern, um sie später im Klartext abzurufen. Wenn Ihre Benutzer Passwörter auf irgendeine Weise im Klartext abrufen können, dann kann dies potenziell auch ein Hacker tun, der eine Sicherheitslücke in Ihrem Code findet. Und das betrifft nicht nur das Passwort eines Benutzers, sondern alle von ihnen.

Wenn Ihre Kunden damit ein Problem haben, teilen Sie ihnen mit, dass das speicherbare Ablegen von Passwörtern gegen das Gesetz verstößt. Hier im Vereinigten Königreich schreibt das Datenschutzgesetz von 1998 (insbesondere Anhang 1, Teil II, Absatz 9) Datenverarbeitern vor, die geeigneten technischen Maßnahmen zu verwenden, um personenbezogene Daten sicher zu halten, unter Berücksichtigung der möglichen Schäden, die entstehen könnten, wenn die Daten kompromittiert würden – was für Benutzer, die Passwörter zwischen verschiedenen Websites teilen, erheblich sein könnte. Wenn sie immer noch Schwierigkeiten haben zu begreifen, dass dies ein Problem darstellt, verweisen Sie sie auf einige konkrete Beispiele, wie dieses hier.

Der einfachste Weg, Benutzern die Wiederherstellung eines Logins zu ermöglichen, besteht darin, ihnen einen einmaligen Link per E-Mail zu senden, über den sie sich automatisch einloggen können und der sie direkt auf eine Seite führt, auf der sie ein neues Passwort wählen können. Erstellen Sie einen Prototyp und zeigen Sie ihn ihnen in Aktion.

Hier sind ein paar Blog-Beiträge, die ich zu diesem Thema geschrieben habe:

• http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-breaking-the-law/
• http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

Update: Wir sehen nun, dass Unternehmen, die es versäumen, die Passwörter ihrer Benutzer ordnungsgemäß zu sichern, mit Klagen und Strafverfolgung konfrontiert werden. Beispiel: LinkedIn mit Sammelklage über 5 Millionen US-Dollar belegt; Sony mit 250.000 Pfund wegen Datenhack bei PlayStation belegt. Wenn ich mich richtig erinnere, hat LinkedIn tatsächlich die Passwörter seiner Benutzer verschlüsselt, aber die Verschlüsselung, die sie verwendet haben, war zu schwach, um effektiv zu sein.