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

1344

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.

Shane
quelle
155
Ich denke er weiß, dass es nicht gut ist. Er sucht immer noch nach der besten Lösung unter den angegebenen Anforderungen.
stefanw
33
Am Ende des Tages müssen Sie lediglich eine vermeidbare Sicherheitsanfälligkeit sorgfältig implementieren.
Turm
20
@Michael Brooks - Ich möchte, dass Sie wissen, dass ich mit CWE-257 absolut einverstanden bin und dieses Wort gerne jedes Mal wörtlich zitieren würde, wenn ich aufgefordert werde, Passwörter als Klartext wiederherstellbar zu machen. In Wirklichkeit interessieren sich Kunden und Benutzer jedoch selten für NIST-Vorschriften und möchten nur, dass ich es trotzdem mache. In 90% der Fälle kann ich sie anders überzeugen, aber in diesen 10% der Fälle, in denen ich nicht kann, versuche ich, die beste Vorgehensweise zu bestimmen - in diesen Fällen liegt CWE-257 (leider) Asche in meiner Hand.
Shane
81
@AviD: Der "niedrige Wert" des Systems hat absolut keinen Einfluss auf dieses Problem, da Benutzer ihre Passwörter wiederverwenden . Warum können die Leute diese einfache Tatsache nicht verstehen? Wenn Sie die Passwörter auf einem "Low Value" -System knacken, haben Sie wahrscheinlich mehrere gültige Passwörter für andere "High Value" -Systeme.
Aaronaught
20
Ein weiterer Punkt wurde ebenfalls beschönigt, den ich gerade im Kommentar zu meiner Antwort erwähnt habe: Woher wissen Sie, dass die Person, die nach diesen Anforderungen fragt, vertrauenswürdig ist? Was ist, wenn die "Usability" -Ausrede nur eine Fassade ist, die eine echte Absicht maskiert, die Passwörter irgendwann in der Zukunft zu stehlen? Ihre Naivität hat Kunden und Aktionäre möglicherweise Millionen gekostet. Wie oft müssen Sicherheitsexperten dies wiederholen, bevor es endgültig einsetzt: Die häufigsten und schwerwiegendsten Sicherheitsbedrohungen sind immer INTERN.
Aaronaught

Antworten:

1037

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.

Michael Burr
quelle
93
+1 für Passphrasen, die derzeit das beste Gleichgewicht zwischen Passwortstärke und Benutzerrückruf bieten.
Aaronaught
197
Sie können auch einen vollständigen Satz bilden, z. B. Das <Adjektiv> <Nomen> ist <verb> <adverb>. Die grüne Katze springt wild. Listen für die Kategorien haben. Mit 1024 Auswahlmöglichkeiten haben Sie jeweils 40 Entropiebits.
Dominik Weber
28
+1 für die Berücksichtigung der Wiederverwendung von Passwörtern als kritisches Problem, um dies zu vermeiden
lurscher
57
"Denken Sie darüber nach - wenn der Benutzer das Passwort abrufen muss, liegt es daran, dass er es vergessen hat" - nicht unbedingt wahr! Ich möchte oft mein Passwort erhalten, weil ich auf dem Laptop bin und ich weiß, dass auf meinem Computer zu Hause mein Passwort gespeichert ist oder es an einem sicheren Ort notiert ist, und ich möchte das nicht brechen, indem ich ein neues bekomme .
Joachim
5
Die Frage mit der höchsten Punktzahl auf der neuen IT Security SE-Site befasst sich mit der Gültigkeit dieser Entropieberechnung. (Nun, technisch gesehen handelt es sich um die xkcd, die @Pieter verlinkt hat.)
Pops
592

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.

Aaronaught
quelle
124
@Aaronaught - Ich denke, das ist ein fairer und gültiger Punkt, aber lassen Sie mich das an Ihnen verdrehen. Sie arbeiten als Mitarbeiter an einem Projekt für ein Unternehmen und Ihr Chef sagt, dies sei eine Anforderung unseres Systems (aus welchem ​​Grund auch immer). Gehst du voller gerechter Empörung von der Arbeit? Ich weiß, dass es eine Verpflichtung gibt, wenn ich die volle Kontrolle habe, verantwortlich zu sein - aber wenn ein Unternehmen das Risiko eingeht, Prüfungen oder Haftung nicht zu bestehen, ist es meine Pflicht, meinen Job zu opfern, um einen Punkt zu beweisen, oder ich suche das BESTE und sicherste Art zu tun, was sie sagen? Ich spiele nur Devil's Advocate.
Shane
44
Ich bin kein Anwalt, aber denke darüber nach. Wenn Ihr Vorgesetzter Sie auffordert, etwas gegen die Interessen des Unternehmens zu tun, z. B. indem Sie sie einer leicht zu vermeidenden Haftung aussetzen, ist es Ihre Aufgabe, zu gehorchen oder höflich abzulehnen? Ja, sie sind Ihr Chef, aber sie haben einen eigenen Chef, auch wenn es die Investoren sind. Wenn Sie nicht über ihre Köpfe gehen, wessen Kopf wird rollen, wenn Ihre Sicherheitslücke ausgenutzt wird? Nur etwas zu beachten.
Steven Sudit
68
Entwickler versuchen immer zu sagen, dass unsere Jobs so viel schwieriger sind als andere, weil wir Müllanforderungen haben, die sich ständig ändern. Nun, dies ist ein perfektes Beispiel dafür, warum; Unser Beruf braucht dringend ein Rückgrat. Unser Beruf muss dringend in der Lage sein zu sagen: "Nein, dies ist keine akzeptable Anforderung. Dies kann ich nicht in gutem Glauben entwickeln. Sie mögen mein Kunde / Arbeitgeber sein, aber ich habe berufliche Verantwortung gegenüber Ihren Kunden und der Öffentlichkeit." und wenn du das willst, musst du woanders suchen. "
Aaronaught
36
@sfussenegger: Du musst den Hintergrund nicht kennen. Es ist inakzeptabel. Sie gehen davon aus, dass der Kunde zu 100% vertrauenswürdig ist. Was ist, wenn er speziell nach dieser Anforderung fragt, damit er später mit den Passwörtern abrechnen kann? Sicherheit ist eines der wenigen Elemente in der Entwicklung , die sich in Stein gemeißelt. Es gibt einige Dinge, die Sie einfach nicht tun, und das Speichern von wiederherstellbaren Passwörtern ist zehn davon.
Aaronaught
37
OK, machen wir hier und jetzt eine Risikobewertung. "Wenn Sie Passwörter in einer wiederherstellbaren Form speichern, besteht ein nicht triviales Risiko, dass Passwörter gestohlen werden. Es ist auch wahrscheinlich, dass zumindest einige Benutzer dieselben Passwörter für ihre E-Mail- und Bankkonten verwenden. Wenn Passwörter gestohlen werden und Bankkonten werden geleert, es wird wahrscheinlich Schlagzeilen machen, niemand wird jemals wieder mit Ihnen Geschäfte machen, und Sie werden wahrscheinlich aus der Existenz verklagt. " Können wir jetzt den Mist schneiden? Die Tatsache, dass Sie das Wort "Nazis" hineingebracht haben, zeigt deutlich, dass Sie keinen Sinn für Vernunft haben.
Aaronaught
206

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).
stefanw
quelle
34
-1 Passwörter sollten niemals "verschlüsselt" werden. Dies
Turm
100
1. In der Frage wurde angegeben, dass das Kennwort im Klartext wiederhergestellt werden kann, daher ist dies eine Voraussetzung. 2. Ich verwende hier asymmetrische Verschlüsselung und keine symmetrische Verschlüsselung. Der Schlüssel zum Entschlüsseln ist für den täglichen Betrieb nicht erforderlich und kann in einem Banksafe aufbewahrt werden. Die Argumentation im Link ist gültig, gilt jedoch nicht für diese Situation.
stefanw
57
Stimmt, aber können Sie zustimmen, dass dies angesichts der Anforderungen die verantwortungsvollste Vorgehensweise ist? Sie können mich den ganzen Tag mit Ihrem CWE-257 erreichen. Es wird nichts an dem interessanten Problem ändern, Anmeldeinformationen sicher zu speichern und damit zu arbeiten und sie bei Bedarf in ihrer ursprünglichen Form wiederherzustellen.
stefanw
10
Der Windows-Wiederherstellungsagent ist auch hier ein schlechtes Beispiel, da er sich mit der tatsächlichen Verschlüsselung und nicht mit der Kennwortverwaltung befasst. Ein Verschlüsselungsschlüssel ist nicht dasselbe wie ein Passwort. Die Regeln und Praktiken sind völlig unterschiedlich. Verschlüsselung und Authentifizierung sind nicht dasselbe. Die Verschlüsselung dient dem Datenschutz - ein Schlüssel wird zum Schutz von Daten verwendet . Die Authentifizierung dient der Identität , wobei der Schlüssel die Daten sind (dies ist ein Faktor im Authentifizierungsprozess). Ich wiederhole also, Verschlüsselung und Authentifizierung sind nicht dasselbe. Sie können die Prinzipien des einen nicht gültig auf das andere anwenden.
Aaronaught
16
+1 Wo ist der Grund, obsessiv auf CWE-257 zu bestehen? Es ist eine Schwäche (CWE), keine Schwachstelle (CVE). Beim Vergleich wiederherstellbarer Passwörter mit Pufferüberläufen werden Äpfel und Orangen verglichen. Stellen Sie einfach sicher, dass der Kunde das Problem versteht (lassen Sie ihn etwas unterschreiben, das dies sagt - andernfalls kann er sich bei Fragen möglicherweise an nichts erinnern), und fahren Sie fort. Darüber hinaus hängen die erforderlichen Sicherheitsmaßnahmen vom Wert des Systems und dem potenziellen Risiko eines Angriffs ab. Wenn ein erfolgreicher Angreifer nur einige Newsletter-Abonnements kündigen konnte, gibt es keinen Grund, über Probleme zu streiten.
Sfussenegger
133

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.

Marquis von Lorne
quelle
2
Webserver-Protokolle zählen vor Gericht nicht? Oder würden sie in diesem Fall auch als gefälscht angenommen?
Vinko Vrsalovic
10
@Vinko Vrsalovic, Webserver-Protokolle sollten nicht vor Gericht gezählt werden. Dazu müssen Sie die Nicht-Zurückweisung, den Echtheitsnachweis, die Beweiskette usw. usw. nachweisen, die Webserver-Protokolle eindeutig nicht sind.
AviD
7
Genau. Der Lieferant muss nachweisen, dass nur der Kunde diese Transaktion hätte durchführen können. Ein Webserver-Protokoll macht das nicht.
Marquis von Lorne
Nicht alle Passwörter werden sozusagen für "Transaktionen" benötigt. Angenommen, die Website dient zum Erstellen einer Lesezeichenliste für Webseiten. In diesem Fall ist die Haftungsbeschränkung (die normalerweise in den AGB bei der Registrierung auf der Website angegeben wird) Null, da keine finanzielle Transaktion vorliegt. Wenn die Website keine Aktionen hat, die andere betreffen, gehen höchstens Daten für den gehackten Benutzer verloren. Das Unternehmen ist durch die AGB geschützt.
Sablefoste
1
@Sablefoste Auf dieser Website. Wenn der Benutzer an anderer Stelle dasselbe Kennwort verwendet, besteht die Gefahr, dass seine privaten Anmeldeinformationen verloren gehen. Wenn Sie nie üben, können Sie das Problem nicht verursachen.
Marquis von Lorne
94

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:

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.

Marmeladenkuchen
quelle
8
@jimmycakes - Dies ist eine gute Sache auf einem System mit geringer Sicherheit. Wenn Sie jedoch Daten von hohem Wert speichern, müssen Sie davon ausgehen, dass die E-Mail-Adresse der Person bereits gefährdet ist und dass das Senden eines direkten Anmeldelinks Ihr System gefährdet. +1 für die Beantwortung meiner Frage mit einer realisierbaren Alternative, aber auf einen Fehler in der Logik insgesamt. Ich möchte nicht, dass Payppal jemals einen direkten Login-Link sendet. Es mag paranoid klingen, aber ich gehe immer davon aus, dass mein E-Mail-Konto beschädigt ist - es hält mich ehrlich. ;)
Shane
Absolut - Ich würde erwarten, dass meine Bank mich zumindest anruft und meine Identität überprüft, bevor ich mein Passwort zurücksetzen ( nicht wiederherstellen) kann. Was ich hier skizziert habe, ist der absolute Mindeststandard an Passwortsicherheit, den ich von jeder Website überall erwarten würde.
Jammycakes
1
Ignorieren Sie die Bank oder Paypal, die die von Ihnen festgelegte Einschränkung ohnehin nicht hätten. Wie ist eine Online-Methode möglich, wenn Sie davon ausgehen, dass ihre E-Mail-Adresse kompromittiert ist? Wenn Sie ein generiertes Passwort per E-Mail senden, wie ist das sicherer?
Peter Coulton
Ich spreche nicht davon, das Passwort einer einzelnen Person zu erhalten, sondern davon, mehrere Passwörter aus einer Datenbank zu erhalten. Wenn ein System Kennwörter wiederherstellbar in Klartext speichert, kann ein Hacker möglicherweise ein Skript schreiben, um alle Kennwörter aus Ihrer Datenbank zu extrahieren.
Jammycakes
Ich frage mich, ob ich einen Link / ein Passwort per E-Mail senden und das Netzwerk in einfacher Form über unbekannte Netzwerkknoten durchlaufen soll ...
Jakub
55

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.

Mr. Boy
quelle
4
@ John - Ich denke, das ist eine absolut praktikable Lösung. Bereiten Sie sich jedoch darauf vor, über interne Bedrohungen geflammt zu werden! Wissen Sie, wenn ich dies mit einem Zwischen-Passwort-Reset tun würde (Tech setzt das Passwort manuell als vorübergehende Maßnahme und weist Mabel an, 1234 als ihr Passwort einzugeben), würde es wahrscheinlich gut auf einem System funktionieren, das keine wichtigen Daten enthält. Wenn es sich jedoch um eine Hochsicherheitsumgebung handelt, haben wir ein Problem, bei dem der Kundendienst das Kennwort des CEO auf 1234 setzen und sich direkt anmelden kann. Es gibt keine perfekte Lösung, aber diese funktioniert in vielen Fällen. (+1)
Shane
5
Ich habe diese Antwort gerade bemerkt. @ Shane, ich verstehe nicht, warum Sie Flammen über "interne Bedrohungen" vorhergesagt haben. Die Möglichkeit, ein Passwort zu ändern, ist keine nennenswerte Schwäche. Das Problem ist die Möglichkeit, ein Passwort zu finden, das wahrscheinlich für andere Dienste verwendet wird - ihre E-Mail, ihre Bank, ihre Online-Shopping-Sites, auf denen ihre CC-Informationen gespeichert sind. Diese Schwäche manifestiert sich hier nicht; Wenn Bob Mabels Passwort zurücksetzt und es ihr telefonisch mitteilt, hat er keinen Zugriff auf eines ihrer anderen Konten. Ich würde jedoch ein Zurücksetzen des Passworts beim Anmelden erzwingen, anstatt es "vorzuschlagen".
Aaronaught
@Aaronaught - Ich verstehe Ihren Standpunkt, aber ich denke an Zeiten, in denen sogar die Kundendienstmitarbeiter von bestimmten Bereichen eines Systems (wie Gehaltsabrechnung, Buchhaltung usw.) ausgeschlossen sind und ihnen erlauben, direkt ein Passwort festzulegen ein Sicherheitsproblem an und für sich. Ich sehe Ihren Standpunkt jedoch darin, dass sich die Art des Systems, über das ich diese Frage gestellt habe, stark von einem internen Buchhaltungssystem unterscheidet. Wir könnten wahrscheinlich eine ganz andere Diskussion über proprietäre interne Systeme und die darin enthaltene Passwortsicherheit führen.
Shane
1
@ Shane: Dann macht die Frage noch weniger Sinn. Ich nahm an, dass Sie wollten, dass jemand ihnen ein Passwort über das Telefon vorliest. Wenn Sie Benutzern ihre Passwörter über ein automatisiertes Self-Service-System per E-Mail senden möchten, können Sie auch ganz auf das Passwort verzichten, da es durch etwas viel Schwächeres "geschützt" wird. Vielleicht müssen Sie viel genauer wissen, welche Art von Usability-Szenarien Sie unterstützen möchten. Vielleicht zeigt Ihnen diese Analyse später, dass wiederherstellbare Passwörter nicht einmal erforderlich sind.
Aaronaught
4
Der von der Support-Person bereitgestellte Code muss nicht unbedingt das neue Passwort sein. Es kann nur ein einmaliger Code sein, der die Funktion zum Zurücksetzen des Passworts entsperrt.
kgilpin
42

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!

Phil H.
quelle
8
Und natürlich können Sie jede geheime Aufteilungstechnik verwenden, um mehrere Personen von Ihrem Unternehmen zur Entschlüsselung zu benötigen. Aber nichts davon erfüllt die ursprünglichen Anforderungen, um einem Benutzer seine Passwörter per E-Mail zu senden oder sich von einem gewöhnlichen Telefon-Unterstützer der ersten Ebene durch die Anmeldung führen zu lassen.
Christopher Creutzig
27

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.
Jacob
quelle
Ich habe auf die Kommentare hier unten in meiner Antwort geantwortet, da sie ziemlich langwierig waren - ich denke, es ist wichtig, die Analyse und die Diskussion der aufgeworfenen Fragen zu überprüfen. stackoverflow.com/questions/2283937/…
AviD
Profitiert der Benutzer davon, dass sein Passwort auf dem Bildschirm angezeigt wird? Meiner Meinung nach - definitiv ja! Jedes Mal, wenn ich ein obskures Passwort aus dem Internet erhalte, danke ich Apple, dass ich es sichtbar machen kann, damit ich es nicht 100 Mal unter Schmerzen erneut eingeben muss. Ich kann mir vorstellen, wie sich eine behinderte Person fühlen würde.
Dmitri Zaitsev
1
Warum ist es besser, ein undurchsichtiges Passwort anzuzeigen, als ein neues Passwort auswählen zu können, an das Sie sich erinnern können?
Jacob
@ Jacob: Mehr Entropie?
Alexander Shcheblikin
25

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.

AviD
quelle
5
Passwörter, die zwischen Ihrer Website mit geringem Wert ohne teure Vermögenswerte und Facebook / GMail / Ihrer Bank geteilt werden , sind selbst auf Websites mit geringem Wert ein teures Gut.
Jammycakes
3
Ich denke, das Problem hierbei ist, dass die oben genannten Benutzergruppen dazu neigen, für alle Anwendungen aus vielen verschiedenen Sicherheitsstufen (vom Bankgeschäft bis zu Rezeptblogs) dasselbe Kennwort zu verwenden. Die Frage ist also, ob es in der Verantwortung des Entwicklers liegt, die Benutzer auch vor sich selbst zu schützen. Ich würde definitiv sagen, ja!
Ercan
7
Es tut mir leid, aber die Identität selbst ist ein wertvolles Gut, Punkt. Keine Ausnahmen, keine Ausreden. Egal wie klein und belanglos Ihre Website ist. Und ein gemeinsames Passwort ist die Identität, wenn es den Hacker in die Facebook-Konten, Google Mail-Konten, Bankkonten usw. Ihrer Benutzer einlässt. Es hat überhaupt nichts mit Semantik zu tun, aber es hat alles mit Konsequenzen zu tun. Fragen Sie einfach jeden, der von einem Hackerangriff wie diesem betroffen war: theregister.co.uk/2009/08/24/4chan_pwns_christians
jammycakes
2
@Jacob, in welcher Welt würde Ihr Kunde verklagt werden, weil Ermas Konten auf anderen Systemen kompromittiert wurden? Selbst bei grober Fahrlässigkeit Ihres Kunden (was, wie ich ausgeführt habe, NICHT selbstverständlich ist) und AUSSER der Tatsache, dass es KEINE MÖGLICHKEIT gibt, zu beweisen, dass das andere System wegen Ihres verletzt wurde, gibt es keine mögliche rechtliche Grundlage dafür Ansprüche jeglicher Art von Schäden von einem System auf dem anderen System geltend machen. Es würde mit Vorurteilen außergerichtlich geworfen werden und den Kläger verachten. Erma ist jedoch möglicherweise schuld an Verstößen gegen zahlreiche Nutzungsbedingungen ...
AviD
5
@ Jacob, das ist so sehr falsch. Nur weil das Passwort zufällig dasselbe ist (was eindeutig gegen Ihre Nutzungsbedingungen und deren Sicherheitsrichtlinien verstoßen würde), ist es nicht rechtlich zulässig, die beiden zu korrolieren. Das ist sogar AUSSERDEM die Tatsache, dass es fast unmöglich wäre, es zu beweisen. Nebenbei möchte ich auch darauf hinweisen, dass es KEIN GESETZ gibt, nach dem ein zufälliges Unternehmen keine laxen Sicherheitspraktiken anwenden muss, es sei denn, bestimmte Vorschriften sind relevant. Und obendrein SIND die Passwörter verschlüsselt (!), So dass die Nachlässigkeit alles andere als eine ausgemachte Sache ist.
AviD
21

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".

Oded
quelle
Weißt du, ich habe das in verschiedenen Situationen verwendet (normalerweise ist dies mein Mittelweg), aber mir wurde gesagt, dass der Endbenutzer die Interaktion einfach nicht bekommen wird und dass der Support in der Lage sein muss, ihnen ihre zu sagen Passwort 'aufgrund von Umständen in diesem Geschäftsmodell'. Ich stimme jedoch zu, dass dies nach Möglichkeit vorzuziehen ist.
Shane
Sie können Ihren Kunden immer über das Risiko informieren, dass ihre Datenbank in böse Hände gerät und sie auf gestohlene Passwörter aufmerksam werden ... Es gibt viele Beispiele.
Oded
6
Bitten Sie sie, das "Design" mit einer zusätzlichen Klausel zu unterschreiben, dass sie Sie nicht verklagen können, wenn das, worüber Sie sie gewarnt haben, tatsächlich passiert ... Zumindest dann decken Sie sich ab.
Oded
4
-1 Passwörter sollten niemals "verschlüsselt" werden. Dies
Turm
34
@ Michael Brooks: Es ist nicht nötig, denselben Kommentar immer wieder herunterzustimmen und zu kopieren und einzufügen. Wir sind uns alle bewusst, dass es eine schlechte Praxis ist. Shane gab jedoch an, dass ihm die Hebelwirkung in dieser Angelegenheit fehlt, und daher werden die nächstbesten Vorschläge gemacht.
Johannes Gorset
13

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.

Nicholas Shanks
quelle
5
Die meisten Benutzer haben keinen PGP-Schlüssel (ich habe immer noch keinen; nach 20 Jahren in der Branche habe ich nie das Bedürfnis verspürt), und es ist kein reibungsloser Prozess, einen zu erhalten. Außerdem ist ein privater Schlüssel sowieso nur ein Proxy für ein tatsächliches Passwort. Mit anderen Worten, es ist ein Passwort für ein Passwort. Es sind Schildkröten den ganzen Weg nach unten.
Robert Harvey
1
@RobertHarvey Das Ziel ist es, einem Benutzer das Abrufen seines Kennworts zu ermöglichen, ohne dass die Mitarbeiter der Website oder Hacker darauf zugreifen können. Indem Sie verlangen, dass der Abrufvorgang auf dem Computer des Benutzers stattfindet, erzwingen Sie dies. Es kann durchaus Alternativen zu PGP geben, die dasselbe erreichen könnten. Schildkröten den ganzen Weg hinunter mögen es sein (vielleicht einige Elefanten auf dem Weg), aber ich sehe keinen anderen Weg. Für die allgemeine Bevölkerung (die wahrscheinlich nicht individuell angesprochen wird) wäre es sicherer als wir derzeit, Ihre Passwörter auf einem Blatt Papier zu haben und sie nicht aus dem Dienst abrufen zu können
Nicholas Shanks,
Ich mag es, weil es jeden dazu zwingt, einen öffentlichen PGP-Schlüssel zu haben, was seltsamerweise eine sehr ethische Sache ist.
Lodewijk
Sie können einfach eine generieren und sie dem Benutzer geben.
My1
@RobertHarvey Sie haben vielleicht Recht, dass dies "kein reibungsloser Prozess" ist, aber es könnte ein zusätzlicher Dienst für Hauptbenutzer sein, den normale Benutzer ignorieren können. Denken Sie daran, dass das Argument, dass eine PK "ein Passwort für ein Passwort" ist, theoretisch für viele Passwörter gelten kann. Sie können unterschiedliche Kennwörter für unterschiedliche Dienste verwenden und alle mit demselben Schlüssel verschlüsseln. Dann ist die PK wertvoller als nur ein einziges Passwort. Vielleicht ist es abstrakt vergleichbar mit einem Passwort-Manager (?). Es ist mir nicht sofort klar, welche Konsequenzen dies haben kann ...
Kjartan
12

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

Z-Boss
quelle
4
@sneg - Nun, ich bin ein äußerst überzeugender Typ, aber manchmal ist es ein Chef und manchmal ein Kunde, so dass ich nicht immer die Hebelwirkung habe, die ich brauche, um sie auf die eine oder andere Weise zu überzeugen. Ich werde aber noch mehr im Spiegel üben ..;)
Shane
Um zu überzeugen, brauchen Sie keine andere Hebelwirkung als Ihre Kompetenz und Kommunikationsfähigkeit. Wenn Sie einen besseren Weg kennen, etwas zu tun, aber die Leute nicht zuhören ... Denken Sie darüber nach.
Z-Boss
7
@ z-chef - Anscheinend hast du nicht mit / für einige der harten Köpfe gearbeitet, mit denen ich das Vergnügen hatte zu arbeiten. Manchmal spielt es keine Rolle, ob Ihre Zunge mit Gold überzogen ist und Sie Google Chrome an einem Tag neu programmieren könnten (was es wahrscheinlich tatsächlich nützlich machen könnte), sie rühren sich immer noch nicht.
Shane
11

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)
  • 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).

Daniel Loureiro
quelle
9

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.

Thomas
quelle
10
In Ihrer Antwort wird völlig ignoriert, dass Kennwörter über mehrere Websites / Dienste hinweg wiederverwendet werden. Dies ist von zentraler Bedeutung für dieses Thema und der Grund, warum wiederherstellbare Kennwörter als schwerwiegende Schwachstelle angesehen werden. Ein Sicherheitsexperte delegiert keine Sicherheitsentscheidungen an den nicht technischen Kunden. Ein Fachmann weiß, dass seine Verantwortung über den zahlenden Kunden hinausgeht und bietet keine Optionen mit hohem Risiko und null Belohnung an. -1 für ein Geschwätz voller Rhetorik und extrem wenig Fakten - und dafür, dass man die Frage nicht einmal wirklich beantwortet.
Aaronaught
4
Auch hier übersehen Sie die Risikobewertung vollständig. Um Ihr Argument zu verwenden, können Sie nicht bei nur Einweg-Hashes anhalten. Sie müssen AUCH Komplexitätsanforderungen, Kennwortlängen, Einschränkungen bei der Wiederverwendung von Kennwörtern usw. angeben. Die Argumentation, dass Benutzer dumme Passwörter verwenden oder Passwörter wiederverwenden, ist keine ausreichende geschäftliche Rechtfertigung, wenn das System irrelevant ist, und ehrlich gesagt habe ich die Frage beantwortet. Die kurze Antwort: Drücken Sie auf die Verwendung einer Standardimplementierung, dokumentieren Sie Ihre Einwände, wenn Sie überstimmt sind, und fahren Sie fort.
Thomas
7
Und wieder wiederholen Sie den Canard, dass nichts davon für ein System mit geringem Wert von Bedeutung ist! Der Wert des Kennworts eines Benutzers hat nichts mit dem Wert eines Benutzerkontos auf Ihrem System zu tun. Es ist ein Geheimnis , das Sie immer behalten müssen. Ich wünschte, ich könnte eine weitere -1 für den Kommentar geben, der zeigt, dass Sie die Probleme hier immer noch nicht verstehen.
Aaronaught
5
Die Risikobewertung ist das Kernthema. Die Wiederverwendung von Passwörtern ist nur ein potenzielles Problem in einer viel größeren Reihe von Problemen. Warum nicht Anhänger benötigen? Warum nicht verlangen, dass die Person zu Ihrem Büro fährt, um sich anzumelden? Ohne eine vernünftige Einschätzung der Risiken gibt es keine Möglichkeit, diese Fragen zu beantworten. In Ihrer Welt ist alles ein Risiko, daher erfordert jedes System Anmeldesicherheit auf FBI-Ebene. So funktioniert die reale Welt einfach nicht.
Thomas
7
Das einzige, was hier klar ist, ist, dass Ihr gesamtes Argument nichts anderes als ein Irrtum bei Slippery Slope ist und dass Sie versuchen, Leser mit Schlagworten wie "Risikobewertung" zu dämpfen, um diese Tatsache zu vertuschen. Seien Sie versichert, dass jedes System, das das "FBI" verwendet, weitaus sicherer ist als ein bcrypt-Hash und eine Mindestkennwortlänge. Wenn das Erfordernis von Authentifizierungssystemen nach Industriestandard mich zu einem "Sicherheitsfanatiker" macht, dann bin ich wohl ein Fanatiker. persönlich schmerzt es mich zu wissen, dass es Leute gibt, die bereit sind, MEINE Sicherheit für Geld zu opfern . Das ist unethisch .
Aaronaught
8

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).

Rob Fonseca-Ensor
quelle
Der Benutzer kann die Frage auch anders beantworten. Einige Fragen erfordern längere Antworten, die später leicht umformuliert werden können.
Monoman
5
Sicherheitsfragen sind eine schlechte Idee. Wie bringen Sie Ihre Mutter dazu, ihren Mädchennamen zu ändern, wenn die Informationen verletzt werden? Siehe auch Peter Gutmanns Engineering Security .
JWW
7

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.

Monoman
quelle
Das vorübergehende Entfernen eines Faktors aus einem Authentifizierungssystem mit mehreren Faktoren ist in der Tat ein viel sichereres Mittel zum Zurücksetzen eines Kennworts als die wütenden "geheimen Fragen" -Systeme, die auf so vielen Websites zu sehen sind. Was das Speichern von Passwörtern in einem wiederherstellbaren Format betrifft, bin ich mir nicht sicher, wie es hilft, es sei denn, Sie verwenden den zweiten Faktor, um den ersten zu verschlüsseln oder zu verschleiern, und ich bin mir nicht sicher, wie dies mit so etwas wie einer SecurID möglich ist. Können Sie erklären?
Aaronaught
@Aaronaught Was ich gesagt habe ist, wenn Sie "wiederherstellbare" Passwörter benötigen, ist das inhärente Risiko geringer, wenn es nicht der einzige Authentifizierungsfaktor ist, und es ist auch für den Endbenutzer einfacher, wenn diese Workflows Faktoren wiederverwenden, die er / sie besitzt und hat bereits aktuellen Zugriff auf wahrscheinlich auch vergessene "geheime Antworten" oder die Verwendung zeitlich begrenzter Links oder temporärer Passwörter, die beide über unsichere Kanäle gesendet werden (es sei denn, Sie verwenden S-MIME mit Client-Zertifikaten oder) PGP, die beide Kosten verursachen, insbesondere für die Verwaltung der korrekten Zuordnung und das Ablaufen / Ersetzen)
Monoman,
1
Ich nehme an, das alles stimmt, aber das Risiko eines öffentlichen Kompromisses ist zunächst minimal. Das schwerwiegendere Problem bei wiederherstellbaren Passwörtern ist die interne Sicherheit, die es einem verärgerten Mitarbeiter möglicherweise ermöglicht, die E-Mail-Passwörter von Tausenden von Kunden zu verwenden, oder einem krummen CEO, sie an Phisher und Spammer zu verkaufen. Die Zwei-Faktor-Authentifizierung eignet sich hervorragend zur Bekämpfung von Identitätsdiebstahl und Kennwortraten, bringt jedoch nicht wirklich viel auf den Tisch, um die tatsächliche Kennwortdatenbank sicher zu halten.
Aaronaught
5

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.

Steven Sudit
quelle
5

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.

Dmitri Zaitsev
quelle
4

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.

devio
quelle
GUID ist eine schlechte Idee, nicht annähernd zufällig genug und leicht zu bruteforce. Es gibt andere Probleme damit, siehe stackoverflow.com/questions/664673/…
AviD
3

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.

casraf
quelle
Ich würde nicht davon ausgehen, dass E-Mails sicherer sind als jedes andere System. Obwohl dies die rechtlichen Bedenken aus meinen Händen nimmt, gibt es immer noch das Problem, dass jemand seine E-Mail verliert / löscht, und jetzt bin ich wieder auf dem ersten Platz.
Shane
Stellen Sie sowohl ein Zurücksetzen des Passworts bereit als auch senden Sie das Klartext-Passwort per E-Mail. Ich denke, das ist das Beste, was Sie zu diesem Thema tun können, ohne selbst eine Kopie des Passworts aufzubewahren.
Casraf
Das ist eine absolut schreckliche Idee. Es ist sowohl ineffektiv (viele Benutzer löschen E-Mails nach dem Lesen tatsächlich) als auch schlimmer als das, wovor Sie sich schützen möchten (da E-Mails standardmäßig unverschlüsselt sind und nicht vertrauenswürdige Netzwerke durchlaufen). Es ist besser, dem Benutzer vorzuschlagen, dass er sich das Passwort selbst notiert und sich zumindest eine E-Mail sendet. Die Informationen gehen nie weiter als bis zum E-Mail-Server, nicht über das gesamte Internet!
Ben Voigt
3

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.

Anopres
quelle
Solange Sie eine E-Mail-Adresse mit einem Kennwort verknüpft haben und dieses Kennwort wiederherstellbar ist, haben Sie möglicherweise das Kennwort für diese E-Mail-Adresse aufgrund der Wiederverwendung des Kennworts verloren. Das ist eigentlich das Hauptanliegen hier. Es gibt wirklich keine anderen personenbezogenen Daten, die wichtig sind.
Aaronaught
1
Sie haben meinen Standpunkt völlig verfehlt. Wenn Sie kein Passwort benötigen, sammeln Sie keines. Entwickler bleiben oft in der Denkweise "So machen wir das" stecken. Manchmal hilft es, vorgefertigte Begriffe wegzuwerfen.
Anopres
2

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?

JonnyBoats
quelle
Ein Hauptschlüssel wäre furchtbar riskant, die Support-Mitarbeiter hätten Zugriff auf jedes Konto - und sobald Sie diesen Schlüssel einem Benutzer geben, haben sie den Hauptschlüssel und Zugriff auf alles.
Carson Myers
Ein Hauptschlüssel ist eine schreckliche Idee, denn wenn jemand ihn entdeckt (oder ihn versehentlich preisgibt), kann er ihn ausnutzen. Da das Zurücksetzen des Passworts pro Konto weitaus vorzuziehen ist.
Phil Miller
Ich bin neugierig, ich dachte, Linux hätte standardmäßig ein Superuser-Konto mit Root-Zugriff? Ist das nicht ein "Hauptschlüssel" für den Zugriff auf alle Dateien auf dem System?
JonnyBoats
@JonnyBoats Ja, das ist es. Aus diesem Grund deaktivieren moderne Unixe wie Mac OS X das Root-Konto.
Nicholas Shanks
@NicholasShanks: Deaktivieren Sie das Root-Konto oder deaktivieren Sie die interaktive Anmeldung für das Root-Konto? Es wird immer noch viel Code mit unbegrenzten Berechtigungen ausgeführt.
Ben Voigt
2

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.

Jeremy C.
quelle
1

Ö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.

Amir Arad
quelle
3
Wenn der App-Server darauf zugreifen kann, kann dies auch jeder tun, der Zugriff auf den App-Server hat (sei es ein Hacker oder ein böswilliger Insider). Dies bietet keine zusätzliche Sicherheit.
Wolf
1
Die zusätzliche Sicherheit besteht darin, dass die Datenbank des Anwendungsservers keine Kennwörter enthält (daher ist ein zweiter Hack erforderlich - für die Kennwortdatenbank) und die Kennwortdatenbank besser vor unregelmäßigen Aktivitäten geschützt werden kann, da Sie die Zugänglichkeit des Kennwortabrufdienstes steuern. So können Sie das Abrufen von Massendaten erkennen, den SSH-Schlüssel für das Abrufen wöchentlich ändern oder sogar das automatische Abrufen von Pässen nicht zulassen und alles manuell ausführen. Diese Lösung passt auch zu jedem anderen internen Verschlüsselungsschema (wie den öffentlichen + privaten Schlüsseln, Salt usw.) für die Kennwortdatenbank.
Amir Arad
1

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.

Sablefoste
quelle
1

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.

Eliott
quelle
Warum ist es Ihrer Meinung nach notwendig, das, was der Benutzer direkt eingegeben hat, mit dem in der Datenbank gespeicherten Hash-Passwort zu vergleichen? Welche Funktionalität bietet Ihnen das? Dabei ist es außerdem äußerst wichtig, eine zeitlich konstante Vergleichsfunktion zwischen dem vom Benutzer eingegebenen Kennwort und dem Hash-Kennwort aus der Datenbank anzuwenden. Andernfalls ist es fast trivial möglich, das Hash-Passwort anhand von Zeitunterschieden zu ermitteln.
Artjom B.
1
@ArtjomB. In der Frage wird gefragt, wie das Kennwort des Benutzers geschützt werden kann, während der Kundensupport (CS) einem Benutzer durch Eingabe seines vergessenen Kennworts eine E-Mail senden kann. Indem die Hash-Version als Klartext-Passwort verwendet werden kann, kann CS sie vorlesen und vom Benutzer anstelle des vergessenen Passworts verwenden lassen. CS kann sich damit auch als Benutzer anmelden und ihn bei einer Aufgabe unterstützen. Auf diese Weise können auch Benutzer geschützt werden, die mit automatisierten Systemen für vergessene Kennwörter vertraut sind, da das von ihnen eingegebene und verwendete Kennwort gehasht wird.
Eliott
Aha. Ich habe die Frage nicht vollständig gelesen. Die Verwendung eines zeitkonstanten Vergleichs ist weiterhin erforderlich, um einen geringfügigen Bruch des gesamten Systems zu verhindern.
Artjom B.