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

Ich denke, die eigentliche Frage, die du dir stellen solltest, ist: 'Wie kann ich besser darin werden, Menschen zu überzeugen?'

Answer 2

Ich habe das gleiche Problem. Und genauso denke ich immer, dass jemand mein System gehackt hat. Es geht nicht darum, "ob", sondern um "wann".

Also, wenn ich eine Website erstellen muss, die vertrauliche Informationen speichern muss, die wiederhergestellt werden können, wie Kreditkarteninformationen oder Passwörter, dann mache ich folgendes:

• Verschlüssele mit: openssl_encrypt (string $data, string $method, string $password)
  • PHP-Handbuch.
• Daten-Argument:
  • die sensiblen Informationen (z. B. das Benutzerpasswort)
  • serialisieren, wenn nötig, z.B. wenn die Informationen ein Array von Daten wie mehrere vertrauliche Informationen sind
• Passwort-Argument: Verwende eine Information, die nur der Benutzer kennt, wie z. B.:
  • das Autokennzeichen des Benutzers
  • Sozialversicherungsnummer
  • Telefonnummer des Benutzers
  • der Name der Mutter des Benutzers
  • eine zufällige Zeichenfolge, die per E-Mail und/oder SMS zur Registrierungszeit gesendet wurde
• Methoden-Argument:
  • wähle eine Verschlüsselungsmethode aus, wie "aes-256-cbc"
• NIEMALS die Informationen, die im "Passwort"-Argument verwendet werden, in der Datenbank (oder an einem anderen Ort im System) speichern

Wenn es notwendig ist, diese Daten abzurufen, verwenden Sie einfach die Funktion "openssl_decrypt()" und fragen Sie den Benutzer nach der Antwort. Z. B .: "Um Ihr Passwort zu erhalten, beantworten Sie die Frage: Was ist Ihre Handynummer?"

PS 1: Verwenden Sie niemals als Passwort eine in der Datenbank gespeicherte Information. Wenn Sie die Handynummer des Benutzers speichern müssen, verwenden Sie diese Information niemals zum Codieren der Daten. Verwenden Sie immer eine Information, die nur der Benutzer kennt oder die es für Außenstehende schwer macht, sie zu kennen.

PS 2: Für Kreditkarteninformationen, wie "One-Click-Kauf", verwende ich das Login-Passwort. Dieses Passwort wird in der Datenbank gehasht (sha1, md5, usw.), aber zum Zeitpunkt des Logins speichere ich das Klartextpasswort in der Sitzung oder in einem nicht persistierenden (d.h. im Speicher) sicheren Cookie. Dieses Klartextpasswort bleibt niemals in der Datenbank, tatsächlich bleibt es immer im Speicher und wird am Ende der Sitzung zerstört. Wenn der Benutzer auf die Schaltfläche "One-Click-Kauf" klickt, verwendet das System dieses Passwort. Wenn der Benutzer mit einem Dienst wie Facebook, Twitter usw. angemeldet war, fordere ich das Passwort erneut an der Kaufzeit an (okay, es ist kein vollständig "One-Click") oder verwende dann einige Daten des Dienstes, mit dem sich der Benutzer angemeldet hat (wie die Facebook-ID).

Answer 3

Die Sicherung von Zugangsdaten ist keine binäre Operation: sicher/unsicher. Sicherheit dreht sich alles um Risikobewertung und wird auf einem Kontinuum gemessen. Sicherheitsfanatiker hassen es, so zu denken, aber die hässliche Wahrheit ist, dass nichts perfekt sicher ist. Gehashte Passwörter mit strengen Passwortanforderungen, DNS-Proben und Netzhaut-Scans sind sicherer, aber mit Entwicklungsaufwand und Benutzererfahrung verbunden. Klartextpasswörter sind bei weitem weniger sicher, aber günstiger zu implementieren (sollten jedoch vermieden werden). Am Ende des Tages geht es um eine Kosten-Nutzen-Analyse eines Sicherheitsvorfalls. Sie implementieren Sicherheit basierend auf dem Wert der gesicherten Daten und deren Zeitwert.

Was kostet es, wenn jemandes Passwort in die Wildnis gerät? Welche Kosten entstehen bei einer unerlaubten Übernahme im gegebenen System? Für die FBI-Computer könnten die Kosten enorm sein. Für Bobs einmalige fünfseitige Website könnten die Kosten vernachlässigbar sein. Ein professioneller Anbieter bietet seinen Kunden Optionen und legt bei Sicherheitsfragen die Vorteile und Risiken jeder Implementierung dar. Dies gilt umso mehr, wenn der Kunde etwas verlangt, das sie aufgrund der Missachtung von Branchenstandards gefährden könnte. Wenn ein Kunde explizit eine Zwei-Wege-Verschlüsselung fordert, würde ich empfehlen, Ihre Einwände zu dokumentieren, aber das sollte Sie nicht davon abhalten, es auf die bestmögliche Weise zu implementieren, die Sie kennen. Am Ende des Tages handelt es sich um das Geld des Kunden. Ja, Sie sollten sich dafür einsetzen, Einweg-Hashes zu verwenden, aber zu behaupten, dass dies absolut die einzige Wahl ist und alles andere unethisch ist, ist völliger Unsinn.

Wenn Sie Passwörter mit Zwei-Wege-Verschlüsselung speichern, kommt es bei Sicherheit alles auf das Schlüsselmanagement an. Windows bietet Mechanismen, um den Zugriff auf Zertifikat-Private Keys auf Administratorkonten und mit Passwörtern zu beschränken. Wenn Sie auf anderen Plattformen hosten, müssen Sie sehen, welche Optionen Ihnen dort zur Verfügung stehen. Wie andere bereits vorgeschlagen haben, können Sie asymmetrische Verschlüsselung verwenden.

Es gibt kein Gesetz (auch nicht das Datenschutzgesetz im Vereinigten Königreich), von dem ich wüsste, das explizit besagt, dass Passwörter mit Einweg-Hashes gespeichert werden müssen. Die einzige Anforderung in all diesen Gesetzen ist einfach, dass angemessene Schritte für die Sicherheit unternommen werden. Wenn der Zugriff auf die Datenbank eingeschränkt ist, können sogar Klartextpasswörter rechtlich unter einer solchen Einschränkung gelten.

Dies bringt jedoch ein weiteres Aspekt zur Sprache: rechtliche Präzedenzfälle. Wenn rechtliche Präzedenzfälle nahelegen, dass Sie Einweg-Hashes verwenden müssen, in der Branche, in der Ihr System erstellt wird, dann ist das etwas ganz anderes. Das ist das Argumentationsmittel, das Sie verwenden, um Ihren Kunden zu überzeugen. Falls dies nicht der Fall ist, ist der beste Vorschlag, eine vernünftige Risikobewertung vorzulegen, Ihre Einwände zu dokumentieren und das System so sicher wie möglich zu implementieren, basierend auf den Anforderungen des Kunden.

Answer 4

Machen Sie die Antwort auf die Sicherheitsfrage des Benutzers zu einem Teil des Verschlüsselungsschlüssels und speichern Sie die Antwort auf die Sicherheitsfrage nicht als Klartext (stattdessen hashen).

Answer 5

Ich implementiere beruflich Mehrfaktor-Authentifizierungssysteme, daher ist es für mich natürlich zu denken, dass man das Passwort entweder zurücksetzen oder rekonstruieren kann, während vorübergehend ein Faktor weniger verwendet wird, um den Benutzer nur für den Rücksetz-/Erstellungs-Workflow zu authentifizieren. Insbesondere die Verwendung von OTPs (Einmalkennwörter) als einige der zusätzlichen Faktoren verringert ein Großteil des Risikos, wenn das Zeitfenster für den vorgeschlagenen Workflow kurz ist. Wir haben Software-OTP-Generatoren für Smartphones implementiert (die die meisten Benutzer bereits ganztägig bei sich tragen) mit großem Erfolg. Bevor Beschwerden über einen kommerziellen Hinweis erscheinen, möchte ich darauf hinweisen, dass wir die inhärenten Risiken reduzieren können, Passwörter leicht abrufbar oder zurücksetzbar zu halten, wenn sie nicht der einzige Faktor zur Authentifizierung eines Benutzers sind. Ich gebe zu, dass die Situation für Wiederverwendung von Passwörtern unter verschiedenen Websites noch nicht ideal ist, da der Benutzer darauf bestehen wird, das ursprüngliche Passwort zu haben, weil er/sie auch die anderen Websites öffnen möchte, aber Sie können versuchen, das rekonstruierte Passwort auf sicherste Weise zu übermitteln (https und diskretes Erscheinungsbild im HTML).