Wie sollte ich ethisch mit dem Speichern von Benutzerkennwörtern umgehen, um später Klartext abzurufen?

Da ich immer mehr Websites und Webanwendungen erstelle, werde ich häufig gebeten, die Kennwörter des Benutzers so zu speichern, dass sie abgerufen werden können, wenn der Benutzer ein Problem hat (entweder um einen Link für ein vergessenes Kennwort per E-Mail zu senden, gehen Sie sie durch Telefon usw.) Wenn ich kann, kämpfe ich bitter gegen diese Praxis und mache viel 'zusätzliche' Programmierung, um das Zurücksetzen von Passwörtern und administrative Unterstützung zu ermöglichen, ohne das tatsächliche Passwort zu speichern.

Wenn ich nicht dagegen ankämpfen kann (oder nicht gewinnen kann), verschlüssele ich das Passwort immer so, dass es zumindest nicht als Klartext in der Datenbank gespeichert wird - obwohl mir bewusst ist, dass meine Datenbank gehackt wird Es würde nicht viel dauern, bis der Täter die Passwörter geknackt hat, was mich unbehaglich macht.

In einer perfekten Welt würden die Leute Passwörter häufig aktualisieren und sie nicht auf vielen verschiedenen Websites duplizieren - leider kenne ich VIELE Leute, die das gleiche Passwort für Arbeit / Zuhause / E-Mail / Bank haben und es mir sogar frei gegeben haben, wenn sie Hilfe benötigen. Ich möchte nicht derjenige sein, der für ihren finanziellen Niedergang verantwortlich ist, wenn meine DB-Sicherheitsverfahren aus irgendeinem Grund fehlschlagen.

Moralisch und ethisch fühle ich mich dafür verantwortlich, für einige Benutzer ihren Lebensunterhalt zu schützen, selbst wenn sie ihn mit viel weniger Respekt behandeln. Ich bin mir sicher, dass es viele Möglichkeiten und Argumente gibt, um Hashes und verschiedene Codierungsoptionen zu salzen, aber gibt es eine einzige „Best Practice“, wenn Sie sie speichern müssen? In fast allen Fällen verwende ich PHP und MySQL, wenn dies einen Unterschied in der Art und Weise macht, wie ich mit den Einzelheiten umgehen soll.

Zusätzliche Informationen für Bounty

Ich möchte klarstellen, dass ich weiß, dass Sie dies nicht tun müssen und dass es in den meisten Fällen am besten ist, dies abzulehnen. Ich bin jedoch nicht auf der Suche nach einem Vortrag über die Vorzüge dieses Ansatzes. Ich suche nach den besten Schritten, die Sie unternehmen können, wenn Sie diesen Ansatz wählen.

In einem Hinweis unten habe ich darauf hingewiesen, dass Websites, die sich hauptsächlich an ältere, geistig behinderte oder sehr junge Menschen richten, für Menschen verwirrend werden können, wenn sie aufgefordert werden, eine sichere Routine zur Wiederherstellung von Passwörtern durchzuführen. Obwohl wir es in diesen Fällen einfach und banal finden, benötigen einige Benutzer die zusätzliche Unterstützung, indem sie entweder von einem Servicetechniker in das System eingewiesen oder direkt per E-Mail / Anzeige benachrichtigt werden.

In solchen Systemen könnte die Abnutzungsrate aufgrund dieser demografischen Daten die Anwendung beeinträchtigen, wenn den Benutzern diese Zugriffsunterstützung nicht gewährt würde. Antworten Sie daher bitte mit einem solchen Setup.

Danke an alle

Dies war eine lustige Frage mit vielen Debatten und ich habe es genossen. Am Ende habe ich eine Antwort ausgewählt, die beide die Kennwortsicherheit beibehält (ich muss keinen Klartext oder wiederherstellbare Kennwörter aufbewahren), aber es auch der von mir angegebenen Benutzerbasis ermöglicht, sich bei einem System anzumelden, ohne die Hauptnachteile, die ich festgestellt habe normale Passwortwiederherstellung.

Wie immer gab es ungefähr 5 Antworten, die ich aus verschiedenen Gründen gerne als richtig markiert hätte, aber ich musste die beste auswählen - der Rest bekam +1. Vielen Dank an alle!

Vielen Dank auch an alle in der Stack-Community, die für diese Frage gestimmt und / oder sie als Favorit markiert haben. Ich nehme das Erreichen von 100 Stimmen als Kompliment und hoffe, dass diese Diskussion jemand anderem mit der gleichen Sorge geholfen hat, die ich hatte.

Wie wäre es mit einem anderen Ansatz oder Blickwinkel bei diesem Problem? Fragen Sie, warum das Kennwort im Klartext vorliegen muss: Wenn der Benutzer das Kennwort abrufen kann, müssen Sie das von ihm festgelegte Kennwort streng genommen nicht wirklich abrufen (er merkt sich sowieso nicht, was es ist) müssen in der Lage sein, ihnen ein Passwort zu geben, das sie verwenden können .

Denken Sie darüber nach: Wenn der Benutzer das Kennwort abrufen muss, liegt es daran, dass er es vergessen hat. 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 darin, dass die generierten Passwörter, die bei einem Rücksetzvorgang erzeugt werden, im Allgemeinen aus einer Reihe zufälliger Zeichen bestehen. Daher ist es für den Benutzer schwierig, sie einfach korrekt einzugeben, es sei denn, sie kopieren-n- Einfügen. Dies kann für weniger versierte Computerbenutzer ein Problem sein.

Eine Möglichkeit, dieses Problem zu umgehen, besteht darin, automatisch generierte Kennwörter bereitzustellen, bei denen es sich um mehr oder weniger natürlichsprachigen Text handelt. Während Zeichenfolgen in natürlicher Sprache möglicherweise nicht die Entropie haben, die eine Zeichenfolge aus zufälligen Zeichen derselben Länge hat, gibt es nichts, was besagt, dass Ihr automatisch generiertes Kennwort nur 8 (oder 10 oder 12) Zeichen enthalten muss. Erhalten Sie eine automatisch generierte Passphrase mit hoher Entropie, indem Sie mehrere zufällige Wörter aneinanderreihen (lassen Sie ein Leerzeichen dazwischen, damit sie für jeden, der lesen kann, erkennbar und typisierbar sind). Sechs zufällige Wörter unterschiedlicher Länge sind wahrscheinlich einfacher korrekt und sicher zu tippen als 10 zufällige Zeichen, und sie können auch eine höhere Entropie aufweisen. Zum Beispiel die Entropie eines 10-stelligen Passworts, das zufällig aus Groß- und Kleinbuchstaben gezogen wird. Ziffern und 10 Interpunktionssymbole (für insgesamt 72 gültige Symbole) hätten eine Entropie von 61,7 Bit. Unter Verwendung eines Wörterbuchs mit 7776 Wörtern (wie von Diceware verwendet), das zufällig für eine Passphrase mit sechs Wörtern ausgewählt werden könnte, hätte die Passphrase eine Entropie von 77,4 Bit. Siehe dieDiceware FAQ für weitere Informationen.

• eine Passphrase mit etwa 77 Entropiebits: "Prosa Flare Table akutes Flair zugeben"

• ein Passwort mit ungefähr 74 Entropiebits: "K: & $ R ^ tt ~ qkD"

Ich weiß, ich würde es vorziehen, die Phrase einzugeben, und mit Copy-n-Paste ist die Phrase nicht weniger einfach zu verwenden als das Passwort, also kein Verlust. Wenn Ihre Website (oder was auch immer das geschützte Asset ist) keine 77-Entropie-Bits für eine automatisch generierte Passphrase benötigt, generieren Sie natürlich weniger Wörter (was Ihre Benutzer sicher zu schätzen wissen).

Ich verstehe die Argumente, dass es passwortgeschützte Assets gibt, die wirklich keinen hohen Wert haben, so dass die Verletzung eines Passworts möglicherweise nicht das Ende der Welt bedeutet. Zum Beispiel wäre es mir wahrscheinlich egal, wenn 80% der Passwörter, die ich auf verschiedenen Websites verwende, verletzt würden: Alles, was passieren könnte, ist, dass jemand für eine Weile unter meinem Namen spammt oder postet. Das wäre nicht großartig, aber es ist nicht so, als würden sie auf mein Bankkonto einbrechen. Angesichts der Tatsache, dass viele Menschen für ihre Webforum-Websites dasselbe Passwort verwenden wie für ihre Bankkonten (und wahrscheinlich für nationale Sicherheitsdatenbanken), halte ich es für am besten, auch diese "geringwertigen" Passwörter als nicht zu behandeln -wiederherstellbar.

Stellen Sie sich vor, jemand hat ein großes Gebäude in Auftrag gegeben - eine Bar, sagen wir - und das folgende 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 zu teuer, ich möchte keine Seitentüren oder Hintertüren.
Architekt: Sir, Notausgänge sind nicht optional, sie sind gemäß dem Brandcode der Stadt erforderlich.
Kunde: Ich bezahle Sie nicht für Streit. Tu einfach was ich gefragt habe.

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

In der Bauindustrie endet das Gespräch höchstwahrscheinlich so:

Architekt: Dieses Gebäude kann nicht ohne Notausgang gebaut werden. Sie können zu jedem anderen lizenzierten Fachmann gehen und er wird Ihnen das Gleiche sagen. Ich gehe jetzt; Rufen Sie mich zurück, wenn Sie zur Zusammenarbeit bereit sind.

Computerprogrammierung kann nicht ein sein lizenzierter Beruf, aber die Leute scheinen sich oft zu fragen, warum unser Beruf nicht den gleichen Respekt genießt wie ein Bau- oder Maschinenbauingenieur - suchen Sie nicht weiter. Diese Berufe werden einfach abgelehnt, wenn ihnen Müll (oder geradezu gefährliche) Anforderungen übergeben werden. Sie wissen, dass es keine Entschuldigung ist zu sagen: "Nun, ich habe mein Bestes gegeben, aber er bestand darauf, und ich muss tun, was er sagt." Sie könnten ihre Lizenz für diese Entschuldigung verlieren.

Ich weiß nicht, ob Sie oder Ihre Kunden Teil eines börsennotierten Unternehmens sind oder nicht, aber das Speichern von Passwörtern in einer wiederherstellbaren Form würde dazu führen, dass Sie verschiedene Arten von Sicherheitsüberprüfungen nicht bestehen. Das Problem ist nicht, wie schwierig es für einen "Hacker", der Zugriff auf Ihre Datenbank hat, wäre, die Passwörter wiederherzustellen. Die überwiegende Mehrheit der Sicherheitsbedrohungen ist intern. Was Sie schützen müssen, ist ein verärgerter Mitarbeiter, der mit allen Passwörtern davonläuft und sie an den Meistbietenden verkauft. Die Verwendung einer asymmetrischen Verschlüsselung und das Speichern des privaten Schlüssels in einer separaten Datenbank verhindern dieses Szenario in keiner Weise. Es wird immer jemanden geben Zugriff auf die private Datenbank hat, und das ist ein ernstes Sicherheitsrisiko.

Es gibt keine ethische oder verantwortungsvolle Möglichkeit, Passwörter in einer wiederherstellbaren Form zu speichern. Zeitraum.

Sie können das Passwort + ein Salt mit einem öffentlichen Schlüssel verschlüsseln. Überprüfen Sie bei Anmeldungen nur, ob der gespeicherte Wert dem aus der Benutzereingabe + Salt berechneten Wert entspricht. Wenn das Kennwort irgendwann im Klartext wiederhergestellt werden muss, können Sie es manuell oder halbautomatisch mit dem privaten Schlüssel entschlüsseln. Der private Schlüssel kann an anderer Stelle gespeichert und zusätzlich symmetrisch verschlüsselt werden (was dann eine menschliche Interaktion erfordert, um das Passwort zu entschlüsseln).

Ich denke, dies ähnelt der Funktionsweise des Windows Recovery Agent .

• Passwörter werden verschlüsselt gespeichert
• Benutzer können sich anmelden, ohne im Klartext zu entschlüsseln
• Passwörter können im Klartext wiederhergestellt werden, jedoch nur mit einem privaten Schlüssel, der außerhalb des Systems gespeichert werden kann (wenn Sie möchten, in einem Banksafe).

Gib nicht auf. Die Waffe, mit der Sie Ihre Kunden überzeugen können, ist die Nicht-Zurückweisbarkeit. Wenn Sie Benutzerkennwörter über einen beliebigen Mechanismus rekonstruieren können, haben Sie ihren Kunden einen legalen Nicht-Ablehnungsmechanismus gegeben, und sie können jede Transaktion ablehnen, die von diesem Kennwort abhängt, da der Lieferant auf keinen Fall nachweisen kann, dass er das Kennwort nicht rekonstruiert hat und setzen Sie die Transaktion durch sich selbst. Wenn Passwörter korrekt als Digests und nicht als Chiffretext gespeichert sind, ist dies unmöglich. Ergo hat entweder der Endkunde die Transaktion selbst ausgeführt oder seine Sorgfaltspflicht bezüglich des Passworts verletzt. In jedem Fall bleibt die Haftung direkt bei ihm. Ich habe an Fällen gearbeitet, in denen sich das auf Hunderte Millionen Dollar belaufen würde. Nicht etwas, was Sie falsch machen wollen.

Sie können Kennwörter nicht ethisch für den späteren Klartextabruf speichern. So einfach ist das. Selbst Jon Skeet kann Passwörter für den späteren Klartextabruf ethisch nicht speichern. Wenn Ihre Benutzer Passwörter im Klartext auf irgendeine Weise abrufen können, kann dies möglicherweise auch ein Hacker tun, der eine Sicherheitslücke in Ihrem Code findet. Dabei wird nicht nur das Kennwort eines Benutzers kompromittiert, sondern alle.

Wenn Ihre Kunden ein Problem damit haben, teilen Sie ihnen mit, dass das Wiederherstellen von Passwörtern gegen das Gesetz verstößt. Hier im Vereinigten Königreich jedenfalls schreibt das Datenschutzgesetz von 1998 (insbesondere Anhang 1, Teil II, Absatz 9) vor, dass die für die Verarbeitung Verantwortlichen die geeigneten technischen Maßnahmen ergreifen müssen, um die Sicherheit personenbezogener Daten zu gewährleisten, unter anderem unter Berücksichtigung der Schaden, der entstehen könnte, wenn die Daten kompromittiert würden - was für Benutzer, die Kennwörter zwischen Websites teilen, erheblich sein kann. Wenn sie immer noch Probleme haben, die Tatsache zu erkennen, dass es sich um ein Problem handelt, verweisen Sie sie auf einige Beispiele aus der Praxis, wie dieses .

Der einfachste Weg, Benutzern das Wiederherstellen eines Logins zu ermöglichen, besteht darin, ihnen einen einmaligen Link per E-Mail zu senden, der sie automatisch anmeldet und sie direkt zu einer Seite führt, auf der sie ein neues Passwort auswählen können. Erstellen Sie einen Prototyp und zeigen Sie ihn ihnen in Aktion.

Hier sind einige 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 jetzt Klagen und Strafverfolgungsmaßnahmen gegen Unternehmen, die die Passwörter ihrer Benutzer nicht ordnungsgemäß sichern. Beispiel: LinkedIn mit einer Sammelklage in Höhe von 5 Millionen US-Dollar geschlagen ; Sony verhängte eine Geldstrafe von 250.000 GBP wegen PlayStation-Datenhacks . Wenn ich mich richtig erinnere, verschlüsselte LinkedIn tatsächlich die Passwörter seiner Benutzer, aber die verwendete Verschlüsselung war zu schwach, um effektiv zu sein.

Nach dem Lesen dieses Teils:

In einem Hinweis unten habe ich darauf hingewiesen, dass Websites, die sich hauptsächlich an ältere, geistig behinderte oder sehr junge Menschen richten, für Menschen verwirrend werden können, wenn sie aufgefordert werden, eine sichere Routine zur Wiederherstellung von Passwörtern durchzuführen. Obwohl wir es in diesen Fällen einfach und banal finden, benötigen einige Benutzer die zusätzliche Unterstützung, indem sie entweder von einem Servicetechniker in das System eingewiesen oder direkt per E-Mail / Anzeige benachrichtigt werden.

In solchen Systemen könnte die Abnutzungsrate aufgrund dieser demografischen Daten die Anwendung beeinträchtigen, wenn den Benutzern diese Zugriffsunterstützung nicht gewährt würde. Antworten Sie daher bitte mit einem solchen Setup.

Ich frage mich, ob eine dieser Anforderungen ein abrufbares Passwortsystem erfordert. Zum Beispiel: Tante Mabel ruft an und sagt "Ihr Internetprogramm funktioniert nicht, ich kenne mein Passwort nicht". "OK", sagt die Kundendienstdrohne, "lassen Sie mich ein paar Details überprüfen und dann gebe ich Ihnen ein neues Passwort . Wenn Sie sich das nächste Mal anmelden, werden Sie gefragt, ob Sie dieses Passwort behalten oder in etwas ändern möchten, an das Sie sich erinnern können." noch einfacher."

Anschließend wird das System so eingerichtet, dass es weiß, wann ein Zurücksetzen des Kennworts erfolgt ist, und die Meldung "Möchten Sie das neue Kennwort behalten oder ein neues auswählen" anzeigt.

Wie ist das schlimmer für die weniger PC-fähigen, als wenn ihnen ihr altes Passwort mitgeteilt wird? Und während der Kundendienstmitarbeiter Unheil anrichten kann, ist die Datenbank selbst viel sicherer, falls sie verletzt 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.

Michael Brooks äußerte sich ziemlich lautstark zu CWE-257 - die Tatsache, dass Sie (der Administrator) das Passwort unabhängig von der von Ihnen verwendeten Methode immer noch wiederherstellen können. Wie wäre es also mit diesen Optionen:

1. Verschlüsseln Sie das Passwort mit dem öffentlichen Schlüssel einer anderen Person - einer externen Behörde. Auf diese Weise können Sie es nicht persönlich rekonstruieren, und der Benutzer muss sich an diese externe Behörde wenden und die Wiederherstellung seines Kennworts beantragen.
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 übertragen Sie sie niemals im Klartext an den Server. Führen Sie zur Wiederherstellung die Entschlüsselung erneut clientseitig durch, indem Sie den Schlüssel aus der Eingabe neu generieren. Zugegeben, bei diesem Ansatz wird im Grunde genommen ein zweites Kennwort verwendet, aber Sie können sie jederzeit anweisen, es aufzuschreiben oder den alten Ansatz für Sicherheitsfragen zu verwenden.

Ich denke, 1. ist die bessere Wahl, da Sie damit jemanden innerhalb des Unternehmens des Kunden bestimmen können, der den privaten Schlüssel besitzt. Stellen Sie sicher, dass sie den Schlüssel selbst generieren, und speichern Sie ihn mit Anweisungen in einem Safe usw. Sie können sogar die Sicherheit erhöhen, indem Sie nur bestimmte Zeichen aus dem Kennwort verschlüsseln und an den internen Dritten weitergeben, damit diese das Kennwort knacken müssen, um es zu erraten es. Wenn sie dem Benutzer diese Zeichen zur Verfügung stellen, werden sie sich wahrscheinlich daran erinnern, was es war!

Als Antwort auf diese Frage wurde viel über Sicherheitsbedenken für den Benutzer diskutiert, aber ich möchte die Vorteile erwähnen. Bisher habe ich keinen legitimen Vorteil für die Speicherung eines wiederherstellbaren Kennworts auf dem System gesehen. Bedenken Sie:

• Profitiert der Benutzer davon, dass ihm sein Passwort per E-Mail zugeschickt wird? Nein. Sie profitieren mehr von einem einmaligen Link zum Zurücksetzen des Passworts, über den sie hoffentlich ein Passwort auswählen können, an 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 eine Support-Person das Passwort mit dem Benutzer spricht? Nein; Wenn die Support-Person die Anforderung des Benutzers nach ihrem Kennwort als ordnungsgemäß authentifiziert erachtet, ist es wiederum für den Benutzer von Vorteil, ein neues Kennwort zu erhalten und die Möglichkeit zu haben, es zu ändern. Außerdem ist der Telefonsupport teurer als das automatische Zurücksetzen von Passwörtern, sodass das Unternehmen auch nicht davon profitiert.

Es scheint, dass die einzigen, die von wiederherstellbaren Passwörtern profitieren können, solche mit böswilliger Absicht oder Unterstützer schlechter APIs sind, die einen Passwortaustausch von Drittanbietern erfordern (bitte verwenden Sie diese APIs niemals!). Vielleicht können Sie Ihr Argument gewinnen, indem Sie Ihren Kunden gegenüber wahrheitsgemäß erklären, dass das Unternehmen keine Vorteile und nur Verbindlichkeiten durch das Speichern wiederherstellbarer Passwörter erhält .

Wenn Sie zwischen den Zeilen dieser Art von Anfragen lesen, werden Sie feststellen, dass Ihre Kunden wahrscheinlich nicht verstehen oder sich überhaupt nicht darum kümmern, wie Kennwörter verwaltet werden. Was sie wirklich wollen, ist ein Authentifizierungssystem, das für ihre Benutzer nicht so schwierig ist. Sie sollten ihnen also nicht nur mitteilen, dass sie keine wiederherstellbaren Kennwörter wünschen, sondern ihnen auch Möglichkeiten bieten, den Authentifizierungsprozess weniger schmerzhaft zu gestalten, insbesondere wenn Sie nicht die hohen Sicherheitsstufen einer Bank benötigen:

• Ermöglichen Sie dem Benutzer, seine E-Mail-Adresse für seinen Benutzernamen zu verwenden. Ich habe unzählige Fälle gesehen, in denen der Benutzer seinen Benutzernamen vergisst, aber nur wenige seine E-Mail-Adresse vergessen.
• Bieten Sie OpenID an und lassen Sie die Kosten für das Vergessen von Benutzern von einem Dritten bezahlen.
• Erleichtern Sie sich die Passwortbeschränkungen. Ich bin sicher, wir waren alle unglaublich verärgert, wenn eine Website Ihr bevorzugtes Passwort aufgrund nutzloser Anforderungen wie "Sie können keine Sonderzeichen verwenden" oder "Ihr Passwort ist zu lang" oder "Ihr Passwort muss beginnen" nicht zulässt mit einem Brief. " Wenn die Benutzerfreundlichkeit ein größeres Problem darstellt als die Kennwortstärke, können Sie auch die nicht dummen Anforderungen lockern, indem Sie kürzere Kennwörter zulassen oder keine Mischung von Zeichenklassen benötigen. Mit gelockerten Einschränkungen verwenden Benutzer mit größerer Wahrscheinlichkeit ein Kennwort, das sie nicht vergessen werden.
• Passwörter nicht ablaufen lassen.
• Ermöglichen Sie dem Benutzer, ein altes Kennwort wiederzuverwenden.
• Ermöglichen Sie dem Benutzer, seine eigene Frage zum Zurücksetzen des Passworts zu wählen.

Wenn Sie jedoch aus irgendeinem Grund (und bitte teilen Sie uns den Grund mit) wirklich, wirklich, wirklich in der Lage sein müssen, ein wiederherstellbares Passwort zu haben, können Sie den Benutzer vor einer möglichen Gefährdung seiner anderen Online-Konten schützen, indem Sie ihm ein Nicht-Passwort geben. basiertes Authentifizierungssystem. Da die Benutzer bereits mit Benutzernamen- / Kennwortsystemen vertraut sind und eine gut ausgeübte Lösung darstellen, wäre dies ein letzter Ausweg, aber es gibt sicherlich viele kreative Alternativen zu Kennwörtern:

• Lassen Sie den Benutzer einen numerischen Stift wählen, vorzugsweise nicht 4-stellig, und vorzugsweise nur, wenn Brute-Force-Versuche geschützt sind.
• Lassen Sie den Benutzer eine Frage mit einer kurzen Antwort auswählen, auf die nur er die Antwort kennt, die sich nie ändern wird, an die er sich immer erinnert und die es anderen Menschen nichts ausmacht, dies herauszufinden.
• Lassen Sie den Benutzer einen Benutzernamen eingeben und zeichnen Sie dann eine leicht zu merkende Form mit ausreichenden Permutationen, um sich vor Vermutungen zu schützen (siehe dieses raffinierte Foto, wie das G1 dies zum Entsperren des Telefons tut).
• Für eine Kinderwebsite können Sie automatisch eine unscharfe Kreatur basierend auf dem Benutzernamen (ähnlich einem Identikon) generieren 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.

Gemäß dem Kommentar, den ich zu der Frage gemacht habe:
Ein wichtiger Punkt wurde von fast allen sehr beschönigt ... Meine anfängliche Reaktion war @Michael Brooks sehr ähnlich, bis ich wie @stefanw feststellte, dass das Problem hier gebrochene Anforderungen sind , aber das sind sie.
Aber dann kam mir der Gedanke, dass dies möglicherweise nicht einmal der Fall ist! Der fehlende Punkt hier ist der unausgesprochene Wert der Assets der Anwendung. Einfach gesagt, für ein System mit geringem Wert wäre ein vollständig sicherer Authentifizierungsmechanismus mit allen damit verbundenen Prozessen übertrieben und falsch Sicherheitsentscheidung.
Für eine Bank sind die "Best Practices" natürlich ein Muss, und es gibt keine Möglichkeit, CWE-257 ethisch zu verletzen. Es ist jedoch leicht, sich Systeme mit geringem Wert vorzustellen, bei denen es sich einfach nicht lohnt (aber ein einfaches Passwort ist immer noch erforderlich).

Es ist wichtig, sich daran zu erinnern, dass echte Sicherheitskompetenz darin besteht, geeignete Kompromisse zu finden und NICHT die "Best Practices", die jeder online lesen kann, dogmatisch auszusprechen.

Als solches schlage ich eine andere Lösung vor:
Abhängig vom Wert des Systems und NUR WENN das System einen angemessen niedrigen Wert ohne "teures" Asset (einschließlich der Identität selbst) aufweist UND es gültige Geschäftsanforderungen gibt, die einen ordnungsgemäßen Prozess gewährleisten unmöglich (oder ausreichend schwierig / teuer), UND der Client wird auf alle Einschränkungen aufmerksam gemacht ...
Dann könnte es angebracht sein, einfach eine reversible Verschlüsselung zuzulassen, ohne dass spezielle Rahmen zum Durchspringen erforderlich sind.
Ich höre nur kurz auf, mich überhaupt nicht mit Verschlüsselung zu beschäftigen, da sie sehr einfach / billig zu implementieren ist (selbst wenn sie als passabel angesehen wird) Schlüsselverwaltung), und es bietet EINIGEN Schutz (mehr als die Kosten für die Implementierung). Es lohnt sich auch zu prüfen, wie Sie dem Benutzer das ursprüngliche Passwort geben können, sei es per E-Mail, Anzeige auf dem Bildschirm usw.
Da hier davon ausgegangen wird, dass der Wert des gestohlenen Passworts (auch insgesamt) recht niedrig ist, kann jede dieser Lösungen gültig sein.

Da in den verschiedenen Posts und separaten Kommentarthreads eine lebhafte Diskussion stattfindet, tatsächlich MEHRERE lebhafte Diskussionen, werde ich einige Klarstellungen hinzufügen und auf einige der sehr guten Punkte antworten, die an anderer Stelle hier angesprochen wurden.

Zunächst einmal denke ich, dass es allen hier klar ist, dass das Abrufen des ursprünglichen Passworts des Benutzers eine schlechte Praxis und im Allgemeinen keine gute Idee ist. Das ist überhaupt nicht umstritten ...
Außerdem werde ich betonen, dass es in vielen, ja den MEISTEN Situationen wirklich falsch ist, sogar schlecht, böse und hässlich .

Der Kern der Frage jedoch um ist das Prinzip , gibt es eine Situation , wo es nicht notwendig sein könnte , dies zu verbieten, und wenn ja, wie dies in der tun korrekteste Art und Weise die Situation angemessen .

Nun, wie @Thomas, @sfussenegger und einige andere erwähnt haben, besteht die einzig richtige Möglichkeit, diese Frage zu beantworten, darin, eine gründliche Risikoanalyse einer bestimmten (oder hypothetischen) Situation durchzuführen , um zu verstehen, worum es geht und wie viel es wert ist, geschützt zu werden und welche anderen Abhilfemaßnahmen spielen eine Rolle, um diesen Schutz zu gewährleisten.
Nein, es ist KEIN Schlagwort, dies ist eines der wichtigsten Werkzeuge für einen echten Sicherheitsexperten. Best Practices sind bis zu einem gewissen Punkt gut (normalerweise als Richtlinien für Unerfahrene und Hacks). Danach übernimmt eine sorgfältige Risikoanalyse.

Weißt du, es ist lustig - ich habe mich immer als einen der Sicherheitsfanatiker betrachtet und irgendwie bin ich auf der anderen Seite dieser sogenannten "Sicherheitsexperten" ... Nun, die Wahrheit ist - weil ich ein Fanatiker bin, und ein wirklicher Sicherheitsexperte aus dem wirklichen Leben - ich glaube nicht daran, "Best Practice" -Dogma (oder CWEs) OHNE diese wichtige Risikoanalyse auszusprechen .
"Passen Sie auf den Sicherheitseifer auf, der schnell alles in seinem Werkzeuggürtel anwendet, ohne zu wissen, gegen welches Problem sie sich tatsächlich verteidigen. Mehr Sicherheit bedeutet nicht unbedingt gute Sicherheit."
Eine Risikoanalyse und echte Sicherheitsfanatiker würden auf einen intelligenteren, wert- / risikobasierten Kompromiss hinweisen, der auf Risiko, potenziellem Verlust, möglichen Bedrohungen, ergänzenden Minderungen usw. basiert. Jeder "Sicherheitsexperte", der nicht auf eine fundierte Risikoanalyse hinweisen kann Die Grundlage für ihre Empfehlungen oder die Unterstützung logischer Kompromisse, aber sie würden es vorziehen, Dogmen und CWEs auszusprechen, ohne zu verstehen, wie eine Risikoanalyse durchzuführen ist, sind nichts anderes als Security Hacks, und ihre Expertise ist das Toilettenpapier nicht wert, auf dem sie es gedruckt haben.

In der Tat bekommen wir so die Lächerlichkeit, die Flughafensicherheit ist.

Bevor wir jedoch über die geeigneten Kompromisse in DIESER SITUATION sprechen, werfen wir einen Blick auf die offensichtlichen Risiken (offensichtlich, da wir nicht alle Hintergrundinformationen zu dieser Situation haben, stellen wir alle Hypothesen auf - da die Frage welche hypothetisch ist Situation könnte es geben ...)
Nehmen wir ein LOW-VALUE-System an, das jedoch nicht so trivial ist, dass es öffentlich zugänglich ist. Der Systembesitzer möchte einen gelegentlichen Identitätswechsel verhindern, doch "hohe" Sicherheit ist nicht so wichtig wie Benutzerfreundlichkeit. (Ja, es ist ein legitimer Kompromiss, das Risiko zu akzeptieren, dass ein erfahrener Script-Kiddie die Site hacken kann ... Warten Sie, ist APT jetzt nicht in Mode ...?)
Nehmen wir zum Beispiel an, ich arrangiere einen einfachen Ort für ein großes Familientreffen, damit jeder überlegen kann, wohin wir dieses Jahr auf unserem Campingausflug gehen möchten. Ich mache mir weniger Sorgen um einen anonymen Hacker oder sogar um Cousin Fred, der wiederholt Vorschläge macht, zum See Wantanamanabikiliki zurückzukehren, da ich befürchte, dass Tante Erma sich nicht anmelden kann, wenn sie muss. Nun, Tante Erma, eine Kernphysikerin, ist nicht sehr gut darin, sich Passwörter zu merken oder überhaupt Computer zu benutzen ... Also möchte ich alle für sie möglichen Reibungen beseitigen. Auch hier mache ich mir KEINE Sorgen um Hacks, ich möchte einfach keine dummen Fehler bei der falschen Anmeldung - ich möchte wissen, wer kommt und was sie wollen.

Wie auch immer.
Was sind hier unsere Hauptrisiken, wenn wir Passwörter symmetrisch verschlüsseln, anstatt einen Einweg-Hash zu verwenden?

• Benutzer imitieren? Nein, ich habe dieses Risiko bereits akzeptiert, nicht interessant.
• Böser Administrator? Nun, vielleicht ... Aber auch hier ist es mir egal, ob sich jemand als ein anderer Benutzer ausgeben kann, INTERN oder nein ... und trotzdem wird ein böswilliger Administrator Ihr Passwort erhalten, egal was passiert - wenn Ihr Administrator schlecht geworden ist, ist das Spiel sowieso vorbei.
• Ein weiteres Problem, das angesprochen wurde, ist die gemeinsame Nutzung der Identität zwischen mehreren Systemen. Ah! Dies ist ein sehr interessantes Risiko, das genauer betrachtet werden muss.
  Lassen Sie mich zunächst behaupten, dass nicht die tatsächliche Identität geteilt wird, sondern der Beweis oder der Authentifizierungsnachweis. Okay, da ein gemeinsames Passwort mir effektiv den Zugang zu einem anderen System ermöglicht (z. B. meinem Bankkonto oder Google Mail), ist dies praktisch dieselbe Identität, also nur Semantik ... Außer, dass es nicht . Die Identität wird in diesem Szenario von jedem System separat verwaltet (obwohl es möglicherweise ID-Systeme von Drittanbietern wie OAuth gibt - dies ist jedoch von der Identität in diesem System getrennt - dazu später mehr).
  Daher besteht das Hauptrisiko hier darin, dass der Benutzer bereitwillig sein (dasselbe) Passwort in mehrere verschiedene Systeme eingibt - und jetzt habe ich (der Administrator) oder ein anderer Hacker meiner Website Zugriff auf die Passwörter von Tante Erma für der Atomraketenstandort.

Hmmm.

Kommt Ihnen hier etwas vor?

Es sollte.

Beginnen wir mit der Tatsache, dass der Schutz des Nuklearraketensystems nicht in meiner Verantwortung liegt. Ich baue nur einen Ausflugsort für Frakkin-Familien (für MEINE Familie). Also, wessen Verantwortung ist es? Umm ... Wie wäre es mit dem Atomraketensystem? Duh.
Zweitens: Wenn ich jemandes Passwort stehlen wollte (jemand, von dem bekannt ist, dass er wiederholt dasselbe Passwort zwischen sicheren und nicht so sicheren Websites verwendet) - warum sollte ich mich dann die Mühe machen, Ihre Website zu hacken? Oder haben Sie Probleme mit Ihrer symmetrischen Verschlüsselung? Meine Güte, ich kann einfach meine eigene einfache Website einrichten und Benutzer dazu bringen, sich anzumelden, um SEHR WICHTIGE NACHRICHTEN über alles zu erhalten, was sie wollen ... Puffo Presto, ich habe ihre Passwörter "gestohlen".

Ja, die Benutzererziehung kommt immer wieder zurück, um uns in die Hienie zu beißen, nicht wahr?
Und Sie können nichts dagegen tun ... Selbst wenn Sie ihre Passwörter auf Ihrer Website hashen und alles andere tun wollten, was die TSA sich vorstellen kann, haben Sie ihr Passwort NICHT EINEN WEISSEN geschützt , wenn sie es behalten wollen Promiskuisch ihre Passwörter in jede Site stecken, auf die sie stoßen. Versuchen Sie es nicht einmal.

Anders ausgedrückt: Sie besitzen keine Passwörter . Versuchen Sie also nicht mehr , sich so zu verhalten, wie Sie es tun.

Also, meine lieben Sicherheitsexperten, als eine alte Dame nach Wendy's fragte: "WO ist das Risiko?"

Noch ein paar Punkte als Antwort auf einige der oben angesprochenen Fragen:

• CWE ist kein Gesetz, keine Vorschrift oder gar ein Standard. Es ist eine Sammlung allgemeiner Schwächen , dh die Umkehrung von "Best Practices".
• Das Problem der gemeinsamen Identität ist ein tatsächliches Problem, das von den Neinsagern hier jedoch missverstanden (oder falsch dargestellt) wird. Es geht darum, die Identität an und für sich (!) Zu teilen und NICHT darum, die Passwörter auf Systemen mit geringem Wert zu knacken. Wenn Sie ein Passwort zwischen einem System mit niedrigem und einem System mit hohem Wert teilen, ist das Problem bereits vorhanden!
• Im Übrigen würde der vorherige Punkt tatsächlich GEGEN die Verwendung von OAuth und dergleichen sowohl für diese Systeme mit geringem Wert als auch für die Bankensysteme mit hohem Wert zeigen.
• Ich weiß, dass es nur ein Beispiel war, aber (leider) sind die FBI-Systeme nicht wirklich die sichersten. Nicht ganz wie die Server Ihres Katzenblogs, aber sie übertreffen auch nicht einige der sichereren Banken.
• Geteiltes Wissen oder doppelte Kontrolle über Verschlüsselungsschlüssel kommt NICHT nur beim Militär vor. Tatsächlich verlangt PCI-DSS dies jetzt von praktisch allen Händlern, so dass es nicht mehr so ​​weit draußen ist (WENN der Wert es rechtfertigt).
• Allen, die sich darüber beschweren, dass Fragen wie diese den Entwicklerberuf so schlecht aussehen lassen: Es sind Antworten wie diese, die den Sicherheitsberuf noch schlechter aussehen lassen. Auch hier ist eine geschäftsorientierte Risikoanalyse erforderlich, andernfalls machen Sie sich unbrauchbar. Zusätzlich zum Unrecht.
• Ich denke, dies ist der Grund, warum es keine gute Idee ist, einfach einen regulären Entwickler zu übernehmen und ihm mehr Sicherheitsverantwortung zu übertragen, ohne zu schulen, anders zu denken und nach den richtigen Kompromissen zu suchen. Nichts für ungut, für diejenigen von euch hier bin ich alles dafür - aber mehr Training ist angebracht.

Wütend. Was für ein langer Beitrag ...
Aber um Ihre ursprüngliche Frage zu beantworten, @Shane:

• Erklären Sie dem Kunden die richtige Vorgehensweise.
• Wenn er immer noch darauf besteht, erklären Sie etwas mehr, bestehen Sie darauf, streiten Sie. Bei Bedarf einen Wutanfall auslösen.
• Erklären Sie ihm das GESCHÄFTSRISIKO. Details sind gut, Zahlen sind besser, eine Live-Demo ist normalerweise am besten.
• WENN ER NOCH darauf besteht UND gültige geschäftliche Gründe vorlegt, ist es Zeit für Sie, ein Urteil zu fällen:
  Ist diese Website von geringem bis keinem Wert? Ist es wirklich ein gültiger Business Case? Ist es gut genug für dich? Gibt es keine anderen Risiken, die Sie berücksichtigen können und die gültige Geschäftsgründe überwiegen würden? (Und natürlich ist der Client KEINE bösartige Site, aber das ist duh).
  Wenn ja, fahren Sie einfach fort. Es ist nicht die Mühe, Reibung und den Verlust der Nutzung (in dieser hypothetischen Situation) wert, den notwendigen Prozess einzurichten. Jede andere Entscheidung (auch in dieser Situation) ist ein schlechter Kompromiss.

Unterm Strich und eine tatsächliche Antwort: Verschlüsseln Sie ihn mit einem einfachen symmetrischen Algorithmus, schützen Sie den Verschlüsselungsschlüssel mit starken ACLs und vorzugsweise DPAPI oder ähnlichem, dokumentieren Sie ihn und lassen Sie den Client (jemanden, der älter genug ist, um diese Entscheidung zu treffen) abmelden es.

Wie wäre es mit einem halben Haus?

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

Anstatt Passwörter zurückzusetzen, können Sie ein Einmalpasswort senden (das geändert werden muss, sobald die erste Anmeldung erfolgt). Lassen Sie den Benutzer dann zu einem beliebigen Passwort wechseln (das vorherige, falls er dies wünscht).

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

Die einzige Möglichkeit, einem Benutzer das Abrufen seines ursprünglichen Kennworts zu ermöglichen, 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 Site (natürlich über SSL), ohne noch ein Passwort festzulegen. Melden Sie sich automatisch an oder geben Sie ein temporäres Passwort ein.
2. Sie bieten an, ihren öffentlichen PGP-Schlüssel für das zukünftige Abrufen von Passwörtern zu speichern.
3. Sie laden ihren öffentlichen PGP-Schlüssel hoch.
4. Sie bitten sie, ein neues Passwort festzulegen.
5. Sie senden ihr Passwort.
6. Sie hashen das Passwort mit dem besten verfügbaren Passwort-Hashing-Algorithmus (z. B. bcrypt). Verwenden Sie diese Option, um die nächste Anmeldung zu überprüfen.
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 sein Kennwort in Zukunft nicht mehr abrufen möchte (er kann es nur auf ein vom Dienst generiertes Kennwort zurücksetzen), können die Schritte 3 und 7 übersprungen werden.

Ich denke, die eigentliche Frage, die Sie sich stellen sollten, lautet: "Wie kann ich Menschen besser überzeugen?"

Ich habe das gleiche Problem. Und gleichzeitig denke ich immer, dass jemand mein System hackt, es geht nicht um "ob", sondern um "wann".

Wenn ich also eine Website erstellen muss, auf der wiederherstellbare vertrauliche Informationen wie eine Kreditkarte oder ein Passwort gespeichert werden müssen, ist dies Folgendes:

• verschlüsseln mit: openssl_encrypt (Zeichenfolge $ data, Zeichenfolge $ method, Zeichenfolge $ password)
  • PHP-Handbuch .
• Daten arg .:
  • die vertraulichen Informationen (z. B. das Benutzerpasswort)
  • Bei Bedarf serialisieren, z. B. wenn die Informationen ein Array von Daten wie mehrere vertrauliche Informationen sind
• Passwort arg : Verwenden Sie Informationen, die nur der Benutzer kennt:
  • das Benutzer-Nummernschild
  • Sozialversicherungsnummer
  • Telefonnummer des Benutzers
  • der Name der Benutzermutter
  • Eine zufällige Zeichenfolge, die zur Registrierungszeit per E-Mail und / oder SMS gesendet wird
• Methode arg :
  • Wählen Sie eine Verschlüsselungsmethode wie "aes-256-cbc".
• Speichern Sie NIEMALS die im Argument "Passwort" verwendeten Informationen in der Datenbank (oder an einer beliebigen Stelle im System).

Wenn Sie diese Daten abrufen möchten, verwenden Sie einfach die Funktion "openssl_decrypt ()" und fragen Sie den Benutzer nach der Antwort. Beispiel: "Um Ihr Passwort zu erhalten, beantworten Sie die Frage: Wie lautet Ihre Handynummer?"

PS 1 : Verwenden Sie niemals Daten, die in der Datenbank gespeichert sind, als Passwort. Wenn Sie die Handynummer des Benutzers speichern müssen, verwenden Sie diese Informationen niemals zum Codieren der Daten. Verwenden Sie immer Informationen, die nur der Benutzer kennt oder die für nicht verwandte Personen schwer zu kennen sind.

PS 2 : Für Kreditkarteninformationen wie "Ein-Klick-Kauf" verwende ich das Login-Passwort. Dieses Passwort wird in der Datenbank (sha1, md5 usw.) gehasht, aber beim Anmelden speichere ich das Klartext-Passwort in einer Sitzung oder in einem nicht persistenten (dh im Speicher) sicheren Cookie. Dieses einfache Passwort bleibt niemals in der Datenbank, sondern bleibt immer im Speicher und wird am Ende des Abschnitts zerstört. Wenn der Benutzer auf die Schaltfläche "Kaufen mit einem Klick" klickt, verwendet das System dieses Kennwort. Wenn der Benutzer mit einem Dienst wie Facebook, Twitter usw. angemeldet war, fordere ich das Passwort beim Kauf erneut auf (ok, es ist kein vollständiger "Klick") oder verwende dann einige Daten des Dienstes, den der Benutzer zum Anmelden verwendet hat (wie die Facebook ID).

Das Sichern von Anmeldeinformationen ist keine binäre Operation: sicher / nicht sicher. Sicherheit dreht sich alles um Risikobewertung und wird an einem Kontinuum gemessen. Sicherheitsfanatiker hassen es, so zu denken, aber die hässliche Wahrheit ist, dass nichts vollkommen sicher ist. Hashed Passwörter mit strengen Passwortanforderungen, DNA-Proben und Retina-Scans sind sicherer, jedoch auf Kosten der Entwicklung und der Benutzererfahrung. Klartext-Passwörter sind weitaus weniger sicher, aber billiger zu implementieren (sollten jedoch vermieden werden). Letztendlich kommt es auf eine Kosten-Nutzen-Analyse eines Verstoßes an. Sie implementieren die Sicherheit basierend auf dem Wert der zu sichernden Daten und ihrem Zeitwert.

Was kostet es, wenn jemandes Passwort in die Wildnis kommt? Was kostet der Identitätswechsel in dem 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 Fachmann bietet seinen Kunden Optionen und legt in Bezug auf die Sicherheit die Vorteile und Risiken einer Implementierung fest. Dies ist doppelt so, wenn der Kunde etwas anfordert, das ihn gefährden könnte, weil er die Industriestandards nicht beachtet. Wenn ein Client speziell eine bidirektionale Verschlüsselung anfordert, würde ich sicherstellen, dass Sie Ihre Einwände dokumentieren. Dies sollte Sie jedoch nicht daran hindern, die bestmögliche Implementierung durchzuführen. Am Ende des Tages ist es das Geld des Kunden. Ja,

Wenn Sie Kennwörter mit bidirektionaler Verschlüsselung speichern, hängt die Sicherheit von der Schlüsselverwaltung ab. Windows bietet Mechanismen, um den Zugriff auf Zertifikate mit privaten Schlüsseln auf Administratorkonten und mit Kennwörtern zu beschränken. Wenn Sie auf anderen Plattformen hosten, müssen Sie sehen, welche Optionen auf diesen verfügbar sind. Wie andere vorgeschlagen haben, können Sie asymmetrische Verschlüsselung verwenden.

Es gibt kein Gesetz (weder das Datenschutzgesetz in Großbritannien), von dem mir bekannt ist, dass Passwörter ausdrücklich in Einweg-Hashes gespeichert werden müssen. Die einzige Anforderung in einem dieser Gesetze ist einfach, dass angemessene Sicherheitsmaßnahmen ergriffen werden. Wenn der Zugriff auf die Datenbank eingeschränkt ist, können auch Klartextkennwörter rechtlich unter eine solche Einschränkung fallen.

Dies bringt jedoch einen weiteren Aspekt ans Licht: den rechtlichen Vorrang. Wenn der rechtliche Vorrang darauf hindeutet, dass Sie in der Branche, in der Ihr System gebaut wird, Einweg-Hashes verwenden müssen, ist dies völlig anders. Mit dieser Munition überzeugen Sie Ihren Kunden. Ansonsten der beste Vorschlag, eine angemessene Risikobewertung vorzunehmen, Ihre Einwände zu dokumentieren und das System so sicher wie möglich zu implementieren, wenn Sie die Anforderungen des Kunden erfüllen.

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 einfachen Text (Hash das stattdessen).

Ich implementiere Authentifizierungssysteme mit mehreren Faktoren, um meinen Lebensunterhalt zu verdienen. Daher ist es für mich selbstverständlich, dass Sie das Kennwort entweder zurücksetzen oder rekonstruieren können, während Sie vorübergehend einen Faktor weniger verwenden, um den Benutzer nur für den Workflow zum Zurücksetzen / Wiederherstellen zu authentifizieren. Insbesondere die Verwendung von OTPs (Einmalkennwörtern) als zusätzliche Faktoren verringert das Risiko erheblich, wenn das Zeitfenster für den vorgeschlagenen Workflow kurz ist. Wir haben mit großem Erfolg Software-OTP-Generatoren für Smartphones implementiert (die die meisten Benutzer bereits den ganzen Tag bei sich tragen). Bevor Beschwerden über einen kommerziellen Plug auftreten, möchte ich sagen, dass wir das Risiko verringern können, dass Passwörter leicht abrufbar oder zurücksetzbar bleiben, wenn sie nicht der einzige Faktor sind, der zur Authentifizierung eines Benutzers verwendet wird.

Entschuldigung, aber solange Sie eine Möglichkeit haben, ihr Passwort zu entschlüsseln, ist es auf keinen Fall sicher. Bekämpfe es bitter und wenn du verlierst, CYA.

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

• Q1. Was sind die tatsächlichen Gründe, warum der Benutzer darauf besteht, auf ein im Klartext gespeichertes Passwort zuzugreifen? Warum ist es so wertvoll?

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

Warum ist es jetzt wichtig? Denn wenn die eigentliche Ursache für Kundenanfragen das System ist, das schmerzlich schwer zu bedienen ist, würde die Behebung der genauen Ursache möglicherweise das eigentliche Problem lösen?

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

Eine andere Frage, die ich gesehen habe, stellte sich:

• Q2. Wenn sich der Benutzer das Passwort nicht an erster Stelle merkt, warum ist das alte Passwort wichtig?

Und hier ist eine mögliche Antwort. Wenn Sie eine Katze namens "miaumiau" haben und ihren Namen als Passwort verwendet haben, dies aber vergessen haben, möchten Sie lieber daran erinnert werden, was es war, oder lieber etwas wie "# zy * RW (ew") erhalten?

Ein weiterer möglicher Grund ist, dass der Benutzer es für eine harte Arbeit hält, ein neues Passwort zu erstellen! Wenn das alte Passwort zurückgeschickt wird, entsteht die Illusion, sie wieder vor dieser schmerzhaften Arbeit zu retten.

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

Als Benutzer möchte ich die Dinge einfach! Ich will 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, wenn jemand Zugriff auf mein "Konto" erhält? Ja, er kann auch die Nachrichten lesen!

Speichert die Site meine "privaten" Informationen? Die Nachrichten, die ich heute gelesen habe? Dann ist es das Problem der Seite, nicht meins! Zeigt die Site authentifizierten Benutzern private Informationen an? Dann zeig es nicht an erster Stelle!

Dies dient nur dazu, die Einstellung des Benutzers zum Problem zu demonstrieren.

Zusammenfassend kann ich sagen, dass es kein Problem ist, Klartext-Passwörter "sicher" zu speichern (von denen wir wissen, dass sie unmöglich sind), sondern das tatsächliche Anliegen der Kunden anzusprechen.

Umgang mit verlorenen / vergessenen Passwörtern:

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

Wenn Benutzer ihre Passwörter vergessen haben, müssen sie mindestens ihre Benutzernamen oder E-Mail-Adressen kennen. Generieren Sie auf Anfrage eine GUID in der Benutzertabelle und senden Sie eine E-Mail mit einem Link, der die Guid als Parameter zur E-Mail-Adresse des Benutzers enthält.

Die Seite hinter dem Link überprüft, ob die Parameter-Guid tatsächlich vorhanden ist (wahrscheinlich mit einer Timeout-Logik), und fragt den Benutzer nach einem neuen Kennwort.

Wenn Sie Hotline-Hilfebenutzer benötigen, fügen Sie Ihrem Zuschussmodell einige Rollen hinzu und lassen Sie die Hotline-Rolle sich vorübergehend als identifizierter Benutzer anmelden. Protokollieren Sie alle diese Hotline-Anmeldungen. Zum Beispiel bietet Bugzilla Administratoren eine solche Identitätswechselfunktion.

Wie wäre es, wenn Sie das Klartext-Passwort bei der Registrierung per E-Mail senden, bevor es verschlüsselt wird und verloren geht? Ich habe viele Websites gesehen, die dies getan haben, und das Abrufen dieses Kennworts aus der E-Mail des Benutzers ist sicherer, als es auf Ihrem Server / Computer zu belassen.

Wenn Sie die Anforderung zum Speichern wiederherstellbarer Kennwörter nicht einfach ablehnen können, wie wäre es damit als Gegenargument.

Wir können entweder Passwörter richtig hashen und einen Rücksetzmechanismus für die Benutzer erstellen, oder wir können alle persönlich identifizierbaren Informationen aus dem System entfernen. Sie können eine E-Mail-Adresse verwenden, um Benutzereinstellungen festzulegen, aber das war es auch schon. Verwenden Sie ein Cookie, um bei zukünftigen Besuchen automatisch Einstellungen abzurufen und die Daten nach einer angemessenen Zeit wegzuwerfen.

Die eine Option, die bei der Kennwortrichtlinie häufig übersehen wird, ist, ob ein Kennwort überhaupt benötigt wird. Wenn Ihre Passwortrichtlinie nur Kundendienstanrufe verursacht, können Sie sie möglicherweise entfernen.

Müssen die Benutzer wirklich wiederherstellen (z. B. erfahren), welches Passwort sie vergessen haben, oder müssen sie einfach in der Lage sein, auf das System zuzugreifen? Wenn sie wirklich ein Passwort für die Anmeldung wünschen, warum nicht eine Routine, 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, das aktuelle Kennwort zu ermitteln, kann es jedoch auf einen neuen Wert zurücksetzen. Natürlich sollten alle derartigen Zurücksetzungen irgendwo protokolliert werden. Es empfiehlt sich, eine E-Mail an den Benutzer zu senden, in der ihm mitgeteilt wird, dass das Kennwort zurückgesetzt wurde.

Eine andere Möglichkeit besteht darin, zwei Kennwörter gleichzeitig zu haben, 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 dem Support-Personal bekannt ist und für alle Benutzer gleich ist. Auf diese Weise kann sich die Support-Person bei Problemen mit dem Hauptschlüssel beim Konto anmelden und dem Benutzer helfen, sein Kennwort auf ein beliebiges Kennwort zu ändern. Selbstverständlich sollten alle Anmeldungen mit dem Hauptschlüssel auch vom System protokolliert werden. Als zusätzliche Maßnahme können Sie bei jeder Verwendung des Hauptschlüssels auch die Anmeldeinformationen der Support-Personen überprüfen.

-EDIT- Als Antwort auf die Kommentare, dass kein Hauptschlüssel vorhanden ist: Ich stimme zu, dass es schlecht ist, genauso wie ich glaube, dass es schlecht ist, anderen als dem Benutzer Zugriff auf das Benutzerkonto zu gewähren. Wenn Sie sich die Frage ansehen, ist die ganze Voraussetzung, dass der Kunde eine stark gefährdete Sicherheitsumgebung vorschreibt.

Ein Hauptschlüssel muss nicht so schlecht sein, wie es zunächst scheint. Ich habe in einem Verteidigungswerk gearbeitet, wo sie die Notwendigkeit erkannten, dass der Mainframe-Computerbetreiber bei bestimmten Gelegenheiten "besonderen Zugang" haben muss. Sie steckten das spezielle Passwort einfach in einen versiegelten Umschlag und klebten es auf den Schreibtisch des Bedieners. Um das Passwort zu verwenden (das der Bediener nicht kannte), musste er den Umschlag öffnen. Bei jedem Schichtwechsel bestand eine der Aufgaben des Schichtleiters darin, zu prüfen, ob der Umschlag geöffnet worden war, und wenn ja, das Passwort (von einer anderen Abteilung) sofort zu ändern und das neue Passwort in einen neuen Umschlag zu legen, und der Prozess begann alles erneut. Der Betreiber würde gefragt, warum er es geöffnet hatte, und der Vorfall würde für die Aufzeichnung dokumentiert.

Dies ist zwar kein Verfahren, das ich entwerfen würde, aber es hat funktioniert und eine hervorragende Rechenschaftspflicht gewährleistet. Alles wurde protokolliert und überprüft, und alle Betreiber hatten geheime DOD-Freigaben und wir hatten nie Missbrauch.

Aufgrund der Überprüfung und Kontrolle wussten alle Betreiber, dass sie, wenn sie das Privileg des Öffnens des Umschlags missbrauchten, sofort entlassen und möglicherweise strafrechtlich verfolgt wurden.

Ich denke, die eigentliche Antwort lautet: Wenn man die Dinge richtig machen will, stellt man Leute ein, denen man vertrauen kann, führt Hintergrundprüfungen durch und übt eine angemessene Kontrolle und Rechenschaftspflicht des Managements aus.

Aber andererseits, wenn der Kunde dieses armen Mannes ein gutes Management hätte, hätten sie nicht in erster Linie nach einer solchen sicherheitsrelevanten Lösung gefragt, oder?

Nach dem Wenigen, das ich über dieses Thema verstehe, glaube ich, dass Sie beim Erstellen einer Website mit einem Anmelde- / Kennwort das Klartextkennwort auf Ihrem Server überhaupt nicht sehen sollten. Das Passwort sollte gehasht und wahrscheinlich gesalzen werden, bevor es den Client überhaupt verlässt.

Wenn Sie das Klartext-Passwort nie sehen, stellt sich die Frage des Abrufs nicht.

Außerdem erfahre ich (aus dem Internet), dass (angeblich) einige Algorithmen wie MD5 nicht mehr als sicher gelten. Ich kann das selbst nicht beurteilen, aber es ist etwas zu beachten.

Öffnen Sie eine Datenbank auf einem eigenständigen Server und stellen Sie jedem Webserver, für den diese Funktion erforderlich ist, eine verschlüsselte Remoteverbindung zur Verfügung.
Es muss keine relationale Datenbank sein, sondern kann ein Dateisystem mit FTP-Zugriff sein, das Ordner und Dateien anstelle von Tabellen und Zeilen verwendet.
Geben Sie den Webservern nur Schreibberechtigungen, wenn Sie können.

Speichern Sie die nicht abrufbare Verschlüsselung des Passworts in der Datenbank der Site (nennen wir es "pass-a"), wie es normale Leute tun :)
Speichern Sie bei jedem neuen Benutzer (oder bei einer Kennwortänderung) eine einfache Kopie des Kennworts in der Remote-Datenbank. Verwenden Sie die Server-ID, die Benutzer-ID und "pass-a" als zusammengesetzten Schlüssel für dieses Kennwort. Sie können das Passwort sogar bidirektional verschlüsseln, um nachts besser schlafen zu können.

Damit jemand sowohl das Passwort als auch den Kontext (Site-ID + Benutzer-ID + "Pass-A") erhalten kann, muss er:

1. Hacken Sie die Datenbank der Website, um ein Paar ("pass-a", Benutzer-ID) oder Paare zu erhalten.
2. Holen Sie sich die ID der Website aus einer Konfigurationsdatei
3. Suchen und Hacken in die Remote-Passwörter-Datenbank.

Sie können die Zugänglichkeit des Kennwortabrufdienstes steuern (ihn nur als gesicherten Webdienst verfügbar machen, nur eine bestimmte Anzahl von Kennwortabrufen pro Tag zulassen, manuell ausführen usw.) und für diese "spezielle Sicherheitsvorkehrung" sogar zusätzliche Gebühren erheben.
Der DB-Server zum Abrufen von Passwörtern ist ziemlich versteckt, da er nicht viele Funktionen erfüllt und besser gesichert werden kann (Sie können Berechtigungen, Prozesse und Dienste genau anpassen).

Alles in allem machen Sie die Arbeit für den Hacker schwieriger. Die Wahrscheinlichkeit einer Sicherheitsverletzung auf einem einzelnen Server ist immer noch gleich, aber aussagekräftige Daten (eine Übereinstimmung von Konto und Kennwort) sind schwer zusammenzustellen.

Eine andere Option, die Sie möglicherweise nicht in Betracht gezogen haben, ist das Zulassen von Aktionen per E-Mail. Es ist etwas umständlich, aber ich habe dies für einen Client implementiert, der Benutzer "außerhalb" ihres Systems benötigte, um bestimmte Teile des Systems anzuzeigen (schreibgeschützt). Zum Beispiel:

1. Sobald ein Benutzer registriert ist, hat er vollen Zugriff (wie eine normale 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 dennoch ausführen, indem er auf eine spezielle Schaltfläche " E-Mail an mich senden " direkt neben dem regulären " Senden " klickt " Schaltfläche " klickt.
3. Die Anfrage wird dann mit einem Hyperlink an die E-Mail gesendet, in dem gefragt wird, ob die Aktion ausgeführt werden soll. Dies ähnelt einem E-Mail-Link zum Zurücksetzen des Kennworts, führt jedoch anstelle des Zurücksetzens des Kennworts die einmalige Aktion aus .
4. Der Benutzer klickt dann auf "Ja" und bestätigt, dass die Daten angezeigt oder die Aktion ausgeführt, Daten enthüllt usw. werden sollen.

Wie Sie in den Kommentaren erwähnt haben, funktioniert dies nicht, wenn die E-Mail kompromittiert ist, aber es geht um den Kommentar von @joachim, dass das Passwort nicht zurückgesetzt werden soll. Möglicherweise müssten sie das Zurücksetzen des Kennworts verwenden, dies könnte jedoch zu einem günstigeren Zeitpunkt oder bei Bedarf mithilfe eines Administrators oder Freundes erfolgen.

Eine Variante dieser Lösung besteht darin, die Aktionsanforderung an einen vertrauenswürdigen Administrator eines Drittanbieters zu senden. Dies funktioniert am besten in Fällen mit älteren, geistig behinderten, sehr jungen oder anderweitig verwirrten Benutzern. Dies erfordert natürlich einen vertrauenswürdigen Administrator, damit diese Personen ihre Aktionen unterstützen können.

Salt-and-Hash das Passwort des Benutzers wie gewohnt. Lassen Sie beim Anmelden des Benutzers sowohl das Kennwort des Benutzers (nach dem Salzen / Hashing) als auch das, was der Benutzer buchstäblich eingegeben hat, übereinstimmen.

Auf diese Weise kann der Benutzer sein geheimes Kennwort eingeben, aber auch die gesalzene / gehashte Version seines Kennworts eingeben, die jemand aus der Datenbank lesen würde.

Grundsätzlich sollte das gesalzene / gehashte Passwort auch ein "Klartext" -Passwort sein.