Frage Wie soll ich den Benutzerpasswortspeicher für späteren Klartextabruf ethisch nähern?


Während ich immer mehr Websites und Webanwendungen erstelle, werde ich oft gebeten, die Passwörter des Benutzers so zu speichern, dass sie bei einem Problem des Benutzers (entweder zum Versenden eines vergessenen Passworts per E-Mail oder über das Internet) abgerufen werden können Telefon, etc.) Wenn ich kann ich bitter gegen diese Praxis kämpfen, und ich mache eine Menge "extra" Programmierung, um das Zurücksetzen von Passwörtern und administrative Unterstützung möglich, ohne ihre tatsächlichen Passwort speichern.

Wenn ich es nicht bekämpfen kann (oder nicht gewinnen kann), kodiere ich das Passwort immer irgendwie, so dass es zumindest nicht als Klartext in der Datenbank gespeichert wird - obwohl mir bewusst ist, dass wenn meine Datenbank gehackt wird Es würde nicht viel für den Täter brauchen, um die Passwörter zu knacken, so dass ich mich unwohl fühle.

In einer perfekten Welt würden Leute Passwörter häufig aktualisieren und sie nicht auf vielen verschiedenen Seiten duplizieren - leider kenne ich VIELE Leute, die dasselbe Work / Home / E-Mail / Bankpasswort haben und es mir sogar freiwillig gegeben haben, wenn sie Hilfe brauchen. Ich möchte nicht derjenige sein, der für ihren finanziellen Untergang verantwortlich ist, wenn meine DB-Sicherheitsverfahren aus irgendeinem Grund fehlschlagen.

Moralisch und ethisch fühle ich mich dafür verantwortlich, das zu schützen, was für manche Nutzer ihr Lebensunterhalt sein kann, auch wenn sie es mit viel weniger Respekt behandeln. Ich bin mir sicher, dass es viele Wege gibt, sich anzumalen und Argumente für Salting-Hashes und verschiedene Codierungsoptionen zu finden, aber gibt es eine einzige "Best Practice", wenn man sie speichern muss? In fast allen Fällen verwende ich PHP und MySQL, wenn das einen Unterschied in der Art und Weise macht, wie ich mit den Besonderheiten umgehen soll.

Zusätzliche Informationen zur Bounty

Ich möchte klarstellen, dass ich weiß, dass dies nicht etwas ist, was Sie tun möchten, und dass die Weigerung in den meisten Fällen am besten ist. Ich bin jedoch nicht auf der Suche nach einem Vortrag über die Vorzüge dieses Ansatzes. Ich suche nach den besten Schritten, die Sie ergreifen müssen, wenn Sie diesen Ansatz verfolgen.

In einem Hinweis unten habe ich darauf hingewiesen, dass Websites, die hauptsächlich auf ältere Menschen, geistig Behinderte oder sehr junge Menschen ausgerichtet sind, für Menschen verwirrend werden können, wenn sie aufgefordert werden, eine sichere Passwortwiederherstellungsroutine durchzuführen. Obwohl wir es einfach und banal finden können, benötigen einige Benutzer die zusätzliche Hilfe, entweder einen Service-Techniker zu haben, der sie in das System einbindet, oder ihnen direkt eine E-Mail zu senden.

In solchen Systemen könnte die Fluktuationsrate aus diesen demografischen Daten die Anwendung humpeln, wenn Benutzern diese Zugriffshilfe nicht gewährt wird. Bitte antworten Sie daher mit einer solchen Konfiguration.

Danke an alle

Das war eine lustige Frage mit vielen Diskussionen und ich habe es genossen. Am Ende habe ich eine Antwort gewählt, die beide die Passwortsicherheit beibehält (ich muss weder Klartext noch wiederherstellbare Passwörter behalten), ermöglicht aber auch, dass sich die von mir angegebene Benutzerbasis in einem System anmeldet, ohne die wesentlichen Nachteile, die ich gefunden habe normale Passwortwiederherstellung.

Wie immer gab es ungefähr 5 Antworten, die ich aus verschiedenen Gründen als korrekt markiert hätte, aber ich musste den besten auswählen - der Rest bekam +1. Danke allen!

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


1346
2018-02-17 19:54


Ursprung


Antworten:


Wie wäre es mit einem anderen Ansatz oder Winkel bei diesem Problem? Fragen Sie, warum das Passwort im Klartext sein muss: Wenn es so ist, dass der Benutzer das Passwort abrufen kann, dann brauchen Sie das Passwort, das Sie festgelegt haben, eigentlich nicht wirklich abzurufen (sie merken sich nicht, was es ist) müssen ihnen ein Passwort geben können Kann benutzen.

Denken Sie darüber nach: Wenn der Benutzer das Passwort 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 üblichen Mechanismen zum Zurücksetzen von Kennwörtern besteht jedoch darin, dass die generierten Kennwörter, die bei einer Zurücksetzungsoperation erzeugt werden, im Allgemeinen eine Reihe zufälliger Zeichen sind. Daher ist es für den Benutzer schwierig, sie einfach korrekt einzugeben, es sei denn, sie kopieren. Einfügen. Das kann ein Problem für weniger versierte Computerbenutzer sein.

Eine Möglichkeit, dieses Problem zu umgehen, ist die Bereitstellung von automatisch generierten Kennwörtern, die mehr oder weniger natürlichsprachig sind. Während natürlichsprachliche Zeichenfolgen möglicherweise nicht die Entropie haben, die eine Zeichenfolge aus zufälligen Zeichen der gleichen Länge hat, gibt es nichts, was besagt, dass Ihr automatisch generiertes Kennwort nur 8 (oder 10 oder 12) Zeichen haben muss. Ermitteln Sie eine automatisch generierte Passphrase mit hoher Entropie, indem Sie mehrere zufällige Wörter aneinander reihen (lassen Sie ein Leerzeichen zwischen ihnen, damit sie von allen, die lesen können, immer noch erkennbar und typisierbar sind). Sechs zufällige Wörter unterschiedlicher Länge sind wahrscheinlich leichter korrekt und vertrauensvoll zu tippen als 10 zufällige Zeichen, und sie können auch eine höhere Entropie haben. Zum Beispiel würde die Entropie eines 10-stelligen Passworts, das zufällig aus Großbuchstaben, Kleinbuchstaben, Ziffern und 10 Interpunktionssymbolen (für insgesamt 72 gültige Symbole) gezogen wird, eine Entropie von 61,7 Bits haben. Unter Verwendung eines Wörterbuchs mit 7776 Wörtern (wie es Diceware verwendet), das für eine aus sechs Wörtern bestehende Passphrase zufällig ausgewählt werden könnte, hätte die Passphrase eine Entropie von 77,4 Bit. Siehe die Diceware FAQ Für mehr Information.

  • eine Passphrase mit ca. 77 Bit Entropie: "Prosa-Flare-Tabelle akutes Flair zugeben"

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

Ich weiß, ich würde es vorziehen, den Ausdruck zu tippen, und mit copy-n-paste ist der Ausdruck nicht weniger einfach zu benutzen als das Passwort, also kein Verlust. Natürlich, wenn Ihre Website (oder was auch immer das geschützte Asset ist) keine 77 Bit Entropie für eine automatisch generierte Passphrase benötigt, generieren Sie weniger Wörter (die Ihre Benutzer sicher schätzen würden).

Ich verstehe die Argumente, dass es passwortgeschützte Assets gibt, die wirklich keinen hohen Wert haben, so dass die Verletzung eines Passworts nicht das Ende der Welt sein kann. Zum Beispiel würde es mir wahrscheinlich egal sein, wenn 80% der Passwörter, die ich auf verschiedenen Websites verwende, verletzt wurden: alles, was passieren könnte, ist eine Person, die eine Zeit lang unter meinem Namen spammt oder posten. Das wäre nicht großartig, aber es ist nicht so, als ob sie in mein Bankkonto einbrechen würden. Angesichts der Tatsache, dass viele Leute das gleiche Passwort für ihre Web-Forum-Sites verwenden wie für ihre Bankkonten (und wahrscheinlich nationale Sicherheitsdatenbanken), denke ich, dass es am besten wäre, selbst diese "Low-Value" Passwörter als nicht zu behandeln -wiederherstellbar.


1039
2018-02-28 08:16



Stellen Sie sich vor, jemand hat ein großes Gebäude in Auftrag gegeben - eine Bar, sagen wir mal - und das folgende Gespräch findet statt:

Architekt:  Für ein Gebäude dieser Größe und Kapazität benötigen Sie hier und hier Notausgänge.
Klient:  Nein, das ist zu kompliziert und teuer in der Wartung, ich will keine Seitentüren oder Hintertüren.
Architekt:  Sir, Notausgänge sind nicht optional, sie sind gemäß der Stadt Feuercode erforderlich.
Klient:  Ich bezahle dich nicht, um zu streiten. Mach einfach das, was ich gefragt habe.

Fragt der Architekt dann, wie man dieses Gebäude ohne Brandausgänge ethisch baut?

In der Bau- und Maschinenbaubranche endet die Konversation höchstwahrscheinlich folgendermaßen:

Architekt:  Dieses Gebäude kann nicht ohne Notausgänge gebaut werden. Sie können zu jedem anderen lizenzierten Profi gehen und er wird Ihnen dasselbe sagen. Ich gehe jetzt; Ruf mich zurück, wenn du bereit bist zu kooperieren.

Computerprogrammierung ist möglicherweise kein lizenziert Englisch: bio-pro.de/en/region/stern/magazin/...2/index.html Aber die Menschen scheinen sich oft zu wundern, warum unser Beruf nicht den gleichen Respekt wie ein Zivil - oder Maschinenbauingenieur genießt - nun, suchen Sie nicht weiter. Diese Berufe werden, wenn sie mit Müll (oder geradezu gefährlichen) Anforderungen konfrontiert werden, einfach ablehnen. Sie wissen, dass es keine Entschuldigung ist zu sagen: "Nun, ich habe mein Bestes gegeben, aber er hat darauf bestanden, 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, aber das Speichern von Kennwörtern in jeder wiederherstellbaren Form würde dazu führen, dass Sie mehrere verschiedene Arten von Sicherheitsaudits durchfallen. Das Problem ist nicht, wie schwierig es für einen "Hacker" wäre, der Zugang zu Ihrer Datenbank hat, um die Passwörter wiederherzustellen. Die überwiegende Mehrheit der Sicherheitsbedrohungen sind intern.  Was Sie dagegen schützen müssen, ist ein unzufriedener Mitarbeiter, der mit allen Passwörtern davonläuft und sie an den Höchstbietenden verkauft. Die Verwendung einer asymmetrischen Verschlüsselung und das Speichern des privaten Schlüssels in einer separaten Datenbank verhindert absolut nichts, um dieses Szenario zu verhindern. es wird immer sein jemand mit Zugriff auf die private Datenbank, und das ist ein ernstes Sicherheitsrisiko.

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


593
2018-02-18 16:05



Sie könnten das Passwort + ein Salz mit einem öffentlichen Schlüssel verschlüsseln. Überprüfen Sie bei Anmeldungen einfach, ob der gespeicherte Wert dem Wert entspricht, der aus der Benutzereingabe + salt berechnet wurde. Kommt es zu einem Zeitpunkt, an dem das Passwort im Klartext wiederhergestellt werden muss, können Sie manuell oder halbautomatisch mit dem privaten Schlüssel entschlüsseln. Der private Schlüssel kann an anderer Stelle gespeichert werden und kann zusätzlich symmetrisch verschlüsselt werden (was eine menschliche Interaktion erfordern wird, um das Passwort dann zu entschlüsseln).

Ich denke, das ist irgendwie ähnlich wie die Windows-Wiederherstellungs-Agent funktioniert.

  • Passwörter werden verschlüsselt gespeichert
  • Benutzer können sich anmelden, ohne sich in 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 (in einem Banksafe, wenn Sie möchten).

206
2018-02-17 20:07



Gib nicht auf. Die Waffe, mit der Sie Ihre Kunden überzeugen können, ist die Unbeweisbarkeit. Wenn Sie Benutzerpasswörter über einen beliebigen Mechanismus rekonstruieren können, haben Sie angegeben ihr Kunden einen gesetzlichen Nichtabstreitungsmechanismus und sie können jede Transaktion, die von diesem Passwort abhängt, zurückweisen, da der Lieferant auf keinen Fall nachweisen kann, dass er das Passwort nicht rekonstruiert und die Transaktion selbst durchgeführt hat. Wenn Passwörter korrekt als Digests und nicht als Chiffretext gespeichert werden, ist dies unmöglich, da entweder der Endkunde die Transaktion selbst ausgeführt hat oder gegen seine Sorgfaltspflicht verstoßen hat. das Passwort. In jedem Fall bleibt die Haftung bei ihm bestehen. Ich habe Fälle bearbeitet, in denen das Hunderte von Millionen Dollar betragen würde. Nicht etwas, das du falsch verstehen willst.


134
2018-02-18 09:59



Sie können Kennwörter nicht ethisch für spätere Klartextabfrage speichern. So einfach ist das. Selbst Jon Skeet kann Passwörter nicht für späteren Klartextabruf ethisch speichern. Wenn Ihre Benutzer Kennwörter irgendwie im Klartext abrufen können, kann dies möglicherweise auch ein Hacker, der eine Sicherheitslücke in Ihrem Code findet. Und das ist nicht nur das Passwort eines Benutzers kompromittiert, aber alle von ihnen.

Wenn Ihre Kunden damit ein Problem haben, sagen Sie ihnen, dass das Wiederherstellen von Passwörtern gegen das Gesetz verstößt. Hier im Vereinigten Königreich jedenfalls verlangt das Datenschutzgesetz von 1998 (insbesondere Anlage 1, Teil II, Absatz 9), dass die für die Verarbeitung Verantwortlichen die geeigneten technischen Maßnahmen ergreifen, um die Sicherheit ihrer personenbezogenen Daten zu gewährleisten, unter anderem unter Berücksichtigung der Schaden, der verursacht werden könnte, wenn die Daten kompromittiert wurden - was für Benutzer, die Passwörter zwischen Sites teilen, erheblich sein kann. Wenn sie immer noch Probleme haben, die Tatsache, dass es ein Problem ist, zu knacken, verweisen Sie sie auf einige Beispiele aus der Praxis, wie z dieses.

Die einfachste Möglichkeit, Benutzern das Wiederherstellen einer Anmeldung zu ermöglichen, besteht darin, ihnen einen einmaligen Link per E-Mail zu senden, der sie automatisch anmeldet und sie direkt auf eine Seite führt, auf der sie ein neues Kennwort auswählen können. Erstellen Sie einen Prototyp und zeigen Sie diesen in Aktion.

Hier sind ein paar Blog-Posts, die ich zu diesem Thema geschrieben habe:

Aktualisieren: Wir fangen jetzt an, Klagen und Strafverfahren gegen Unternehmen zu sehen, die die Passwörter ihrer Nutzer nicht richtig schützen. Beispiel: LinkedIn schlug mit $ 5 Millionen Sammelklage; Sony hat 250.000 £ wegen PlayStation-Daten-Hacks bestraft. Wenn ich mich recht erinnere, verschlüsselte LinkedIn tatsächlich die Passwörter seiner Benutzer, aber die verwendete Verschlüsselung war zu schwach, um effektiv zu sein.


95
2018-02-23 15:20



Nach dem Lesen dieses Teils:

In einer Notiz unten machte ich den Punkt, dass   Websites, die weitgehend auf die   ältere, geistig behinderte oder sehr   Junge können für Menschen verwirrend werden   wenn sie gebeten werden, a   sichere Passwortwiederherstellungsroutine.   Obwohl wir es einfach finden können und   banal in diesen Fällen brauchen einige Benutzer   die zusätzliche Unterstützung von entweder   Ein Servicetechniker hilft ihnen dabei   System oder per E-Mail / Anzeige   direkt zu ihnen.

In solchen Systemen ist die Ausfallrate   Von diesen Demografien könnte humpeln   die Anwendung, wenn die Benutzer nicht waren   angesichts dieser Ebene der Zugangshilfe,   also antworte bitte mit einem solchen Setup in   Verstand.

Ich frage mich, ob eine dieser Anforderungen ein abrufbares Passwortsystem vorschreibt. 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 werde ich." gebe dir ein neues Passwort. Wenn Sie sich das nächste Mal anmelden, werden Sie gefragt, ob Sie das Passwort behalten oder es in etwas ändern möchten, an das Sie sich leichter erinnern können. "

Dann wird das System eingerichtet, um zu wissen, wann ein Zurücksetzen des Passworts stattgefunden hat, und zeigt eine Nachricht "Möchten Sie das neue Passwort behalten oder eine neue wählen" an.

Wie ist das für die weniger PC-gebildeten schlechter, als ihr altes Passwort zu sagen? Und während die Kundendienstperson Unfug treiben kann, ist die Datenbank selbst viel sicherer, falls sie verletzt wird.

Kommentieren Sie, was auf meinem Vorschlag schlecht ist, und ich werde eine Lösung vorschlagen, die tatsächlich das tut, was Sie ursprünglich wollten.


55
2018-02-25 11:27



Michael Brooks war ziemlich laut über CWE-257 - die Tatsache, dass Sie (der Administrator) immer noch das Passwort wiederherstellen können, egal welche Methode Sie verwenden. Wie wäre es mit diesen Optionen:

  1. Verschlüsseln Sie das Passwort mit von jemand anderem Öffentlicher Schlüssel - irgendeine externe Autorität. Auf diese Weise können Sie es nicht persönlich rekonstruieren, und der Benutzer muss zu dieser externen Autorität gehen und um die Wiederherstellung seines Passworts bitten.
  2. Verschlüsseln Sie das Passwort mit einem Schlüssel, der aus einer zweiten Passphrase generiert wurde. Tun Sie diese Verschlüsselung clientseitig und übertragen Sie diese niemals im Klartext an den Server. Um die Wiederherstellung durchzuführen, führen Sie die Entschlüsselung erneut auf der Clientseite durch, indem Sie den Schlüssel aus der Eingabe neu generieren. Zugegebenermaßen verwendet dieser Ansatz im Grunde ein zweites Passwort, aber Sie können ihm immer sagen, dass er es aufschreiben soll oder den alten Sicherheitsfragen-Ansatz verwenden.

Ich denke 1. ist die bessere Wahl, weil es Ihnen ermöglicht, jemanden innerhalb der Firma des Kunden zu bestimmen, um den privaten Schlüssel zu halten. Stellen Sie sicher, dass sie den Schlüssel selbst generieren und mit Anweisungen in einem Safe usw. speichern. Sie könnten sogar Sicherheit hinzufügen, indem Sie nur bestimmte Zeichen des Kennworts verschlüsseln und dem internen Dritten zur Verfügung stellen, so dass sie das Passwort knacken müssen, um zu erraten es. Wenn Sie diese Zeichen dem Benutzer zur Verfügung stellen, werden sie sich wahrscheinlich daran erinnern, was es war!


42
2018-02-18 13:56



Es gab eine Menge Diskussion über Sicherheitsbedenken für den Benutzer als Antwort auf diese Frage, aber ich möchte eine Erwähnung von Vorteilen hinzufügen. Bisher habe ich nicht gesehen ein legitimer Vorteil erwähnt, dass ein wiederherstellbares Passwort auf dem System gespeichert ist. Bedenken Sie:

  • Profitiert der Benutzer davon, dass sein Passwort per E-Mail an sie gesendet wird? Nein. Sie erhalten mehr von einem Link zum einmaligen Zurücksetzen des Passworts, der es ihnen hoffentlich ermöglicht, ein Passwort zu wählen werden merken.
  • 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 Supportperson das Passwort für den Benutzer spricht? Nein; Wenn die Support-Person die Anfrage des Benutzers nach ihrem Passwort als korrekt authentifiziert ansieht, ist es wiederum für den Benutzer von Vorteil, ein neues Passwort und die Möglichkeit, es zu ändern, zu erhalten. Darüber hinaus ist die telefonische Unterstützung teurer als das automatische Zurücksetzen des Passworts, so dass das Unternehmen auch nicht davon profitiert.

Es scheint, als seien die einzigen, die von wiederherstellbaren Passwörtern profitieren könnten, diejenigen mit böswilligen Absichten oder Unterstützer von schlechten APIs, die einen Passwortaustausch durch Dritte erfordern (bitte benutze diese APIs nie!). Vielleicht können Sie Ihr Argument gewinnen, indem Sie Ihren Kunden das wahrheitsgemäß mitteilen Die Firma erhält keine Vorteile und nur Verbindlichkeiten, indem sie wiederherstellbare Passwörter speichert.

Wenn Sie zwischen den Zeilen dieser Anforderungsarten lesen, werden Sie feststellen, dass Ihre Clients die Verwaltung von Kennwörtern wahrscheinlich überhaupt nicht verstehen oder überhaupt kümmern. Was sie wirklich wollen, ist ein Authentifizierungssystem das ist nicht so schwer für ihre Benutzer. Sie sollten ihnen also nicht nur mitteilen, dass sie keine wiederherstellbaren Kennwörter benötigen, sondern auch Möglichkeiten, um den Authentifizierungsprozess weniger schmerzhaft zu machen, insbesondere wenn Sie nicht die hohen Sicherheitsstufen einer Bank benötigen:

  • Erlaube 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 vergessen ihre E-Mail-Adresse.
  • Bieten Sie OpenID an und lassen Sie sich von einem Dritten für die Kosten der Nutzervergesslichkeit bezahlen.
  • Erleichtern Sie sich die Passwortbeschränkungen. Ich bin mir sicher, dass wir alle unglaublich genervt sind, wenn eine Website Ihr bevorzugtes Passwort aufgrund von nutzlosen Anforderungen wie "Sie können keine Sonderzeichen verwenden" oder "Ihr Passwort ist zu lang" oder "Ihr Passwort muss starten mit einem Brief. " Wenn die Benutzerfreundlichkeit ein größeres Problem ist als die Passwortstärke, können Sie auch die nicht-dummen Anforderungen lösen, indem Sie kürzere Passwörter zulassen oder keine Kombination von Zeichenklassen benötigen. Mit gelockerten Einschränkungen werden Benutzer eher ein Passwort verwenden, das sie nicht vergessen werden.
  • Verfallen Sie keine Passwörter.
  • Erlaube dem Benutzer, ein altes Passwort wiederzuverwenden.
  • Erlaube dem Benutzer, seine eigene Passwort-Reset-Frage zu wählen.

Aber wenn Sie, aus irgendeinem Grund (und bitte sagen Sie uns den Grund) wirklich, wirklich, wirklich Um ein wiederherstellbares Passwort zu erhalten, könnten Sie den Benutzer davor schützen, ihre anderen Online-Konten möglicherweise zu kompromittieren, indem Sie ihnen ein Passwort-basiertes Authentifizierungssystem geben. Da Benutzer bereits mit Benutzernamen / Passwort-Systemen vertraut sind und eine gut ausgeführte Lösung bieten, wäre dies ein letzter Ausweg, aber es gibt sicherlich viele kreative Alternativen zu Passwörtern:

  • Lassen Sie den Benutzer einen numerischen Pin wählen, vorzugsweise nicht 4-stellig, und vorzugsweise nur dann, wenn Brute-Force-Versuche davor geschützt sind.
  • Lassen Sie den Benutzer eine Frage mit einer kurzen Antwort wählen, dass nur sie die Antwort wissen, sich nie ändern werden, sie werden sich immer daran erinnern, und es macht ihnen nichts aus, dass andere Leute es herausfinden.
  • Lassen Sie den Benutzer einen Benutzernamen eingeben und zeichnen Sie dann eine leicht zu merkende Form mit ausreichenden Permutationen, um gegen Raten zu schützen (siehe dieses geschickte Foto wie das G1 dies zum Entsperren des Telefons macht).
  • Für eine Kinderwebsite könnten Sie automatisch eine unscharfe Kreatur basierend auf dem Benutzernamen (ähnlich wie ein Identicon) 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 einzuloggen.

28
2018-02-27 20:10



Gemäß dem Kommentar, den ich zu der Frage gemacht habe:
Ein wichtiger Punkt wurde von fast allen sehr beschönigt ... Meine erste Reaktion war sehr ähnlich zu @Michael Brooks, bis ich, wie @stefanw, erkannte, dass das Problem hier gebrochene Anforderungen sind, aber das sind sie.
Aber dann ist mir aufgefallen, dass das vielleicht nicht einmal der Fall ist! Der fehlende Punkt hier ist das Unausgesprochene Wert der Vermögenswerte der Anwendung. Für ein System mit geringem Wert wäre ein vollständig sicherer Authentifizierungsmechanismus mit all dem involvierten Prozess ein Overkill und die falsch Sicherheitswahl.
Offensichtlich sind für eine Bank die "Best Practices" ein Muss, und es gibt keine Möglichkeit, CWE-257 ethisch zu verletzen. Aber es ist leicht, an Systeme mit geringem Wert zu denken, wo 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 zwar NICHT darin, die "Best Practices", die jeder online lesen kann, dogmatisch auszuspeien.

Daher schlage ich eine andere Lösung vor:
Abhängig vom Wert des Systems und NUR WENN das System ist angemessen niedrigwertig ohne "teures" Gut (die Identität selbst, enthalten), UND Es gibt gültige Geschäftsanforderungen, die einen ordnungsgemäßen Prozess unmöglich machen (oder ausreichend schwierig / teuer). UND der Kunde wird auf alle Vorbehalte aufmerksam gemacht ...
Dann könnte es angebracht sein, einfach eine reversible Verschlüsselung zu erlauben, ohne dass spezielle Ringe durchspringen müssen.
Ich höre gerade auf zu sagen, dass ich mich überhaupt nicht mit der Verschlüsselung beschäftige, weil es sehr einfach / billig zu implementieren ist (sogar unter Berücksichtigung passabler Schlüsselverwaltung), und es bietet EINIGEN Schutz (mehr als die Kosten der Implementierung). Es lohnt sich auch, herauszufinden, wie man dem Benutzer das ursprüngliche Passwort zur Verfügung stellt, sei es per E-Mail, auf dem Bildschirm, usw.
Da die Annahme hier ist, dass der Wert des gestohlenen Passworts (sogar insgesamt) ziemlich niedrig ist, kann jede dieser Lösungen gültig sein.


Da es eine lebhafte Diskussion gibt, tatsächlich mehrere lebhafte Diskussionen, in den verschiedenen Posts und separaten Kommentarfäden, werde ich einige Klarstellungen hinzufügen und auf einige der sehr guten Punkte antworten, die an anderer Stelle hier aufgeworfen wurden.

Zu Beginn denke ich, dass hier jedem klar ist, dass das Abrufen des ursprünglichen Passworts des Benutzers eine schlechte Übung ist und im Allgemeinen keine gute Idee ist. Das ist überhaupt nicht strittig ...
Außerdem werde ich betonen, dass in vielen, nein die meisten Situationen - es ist wirklich falsch, sogar faul, böse, und hässlich.

Der Kern der Frage ist jedoch um das Prinzip, Gibt es Situationen, in denen es nicht notwendig ist dies zu verbieten, und wenn ja, wie dies in der korrekteste Art und Weise, die der Situation angemessen ist.

Jetzt, wie @Thomas, @sfussenegger und einige andere erwähnt haben, ist der einzig richtige Weg, diese Frage zu beantworten, ein gründliches zu tun Risikoanalyse jeder gegebenen (oder hypothetischen) Situation, um zu verstehen, was auf dem Spiel steht, wie viel es wert ist, zu schützen, und welche anderen Milderungen im Spiel sind, um diesen Schutz zu leisten.
Nein, es ist kein Schlagwort, dies ist eines der grundlegenden und wichtigsten Tools für einen echten Sicherheitsexperten. Best Practices sind bis zu einem gewissen Punkt gut (normalerweise als Richtlinien für Unerfahrene und Hacks), nach diesem Punkt übernimmt eine durchdachte Risikoanalyse.

Weißt du, es ist lustig - ich habe mich immer für einen der Sicherheitsfanatiker gehalten, 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) herauszuschleudern, OHNE dass das alles so wichtig ist Risikoanalyse.
"Passen Sie auf, dass die Sicherheitsexperten, die schnell alles in ihrem Werkzeuggürtel anwenden, nicht wissen, wogegen sie sich eigentlich verteidigen. Mehr Sicherheit bedeutet nicht unbedingt eine gute Sicherheit."
Risikoanalyse und wahre Sicherheitsfanatiker würden auf eine klügere, Wert / Risiko-basierte Abwägung hinweisen, basierend auf Risiko, potentiellem Verlust, möglichen Bedrohungen, ergänzenden Entschärfungen usw. Jeder "Sicherheitsexperte", der nicht auf eine fundierte Risikoanalyse verweisen kann wie der Grundlage für ihre Empfehlungen, oder unterstützen logische Kompromisse, sondern würden lieber Dogma und CWEs ausspucken, ohne sogar zu verstehen, wie man eine Risikoanalyse durchführt, sind nichts als Security Hacks, und ihre Expertise ist das Toilettenpapier wert, auf dem sie gedruckt wurden.

In der Tat bekommen wir die Lächerlichkeit der Flughafensicherheit.

Aber bevor wir über die entsprechenden Kompromisse sprechen, die wir in DIESER LAGE machen müssen, werfen wir einen Blick auf die scheinbaren Risiken (offensichtlich, weil wir nicht alle Hintergrundinformationen über diese Situation haben, die wir alle hypothetisieren - da die Frage hypothetisch ist) Situation könnte dort sein ...)
Nehmen wir ein LOW-VALUE-System an, aber nicht so trivial, dass es öffentlich zugänglich ist - der Systemeigentümer möchte einen zufälligen Identitätswechsel verhindern, aber "hohe" Sicherheit ist nicht so wichtig wie die Benutzerfreundlichkeit. (Ja, es ist ein legitimer Kompromiss, das Risiko einzugehen, dass ein kompetenter Script-Kiddie die Seite hacken kann ... Warte, ist APT jetzt nicht in Mode?)
Nehmen wir zum Beispiel an, ich arrangiere eine einfache Site für ein großes Familientreffen, bei dem jeder darüber nachdenken kann, wohin wir dieses Jahr auf unseren Campingausflug gehen wollen. Ich mache mir weniger Sorgen um einen anonymen Hacker, oder sogar Cousin Fred, der wiederholt Vorschläge einbringt, um zum Lake Wantanamanabikiliki zurückzukehren, da ich davon ausgehe, dass Tante Erma sich nicht einloggen kann, wenn sie muss. Nun, Tante Erma, eine Atomphysikerin, ist nicht besonders gut darin, sich an Passwörter zu erinnern oder überhaupt Computer zu benutzen ... Also möchte ich alle möglichen Reibungen für sie entfernen. Nochmal, ich mache mir keine Sorgen wegen Hacks, ich will einfach keine dummen Fehler mit falschem Login - ich will wissen, wer kommt und was sie wollen.

Sowieso.
Was sind also unsere Hauptrisiken, wenn wir Passwörter symmetrisch verschlüsseln anstatt einen Einweg-Hash zu verwenden?

  • Sich als Benutzer ausgeben? Nein, ich habe dieses Risiko bereits akzeptiert, nicht interessant.
  • Schlechter Administrator? Nun, vielleicht ... Aber wieder ist es mir egal, ob jemand einen anderen Benutzer annehmen kann, INTERNAL oder nein ... und sowieso wird ein böswilliger Administrator Ihr Passwort bekommen egal was - Wenn dein Admin schlecht läuft, ist sein Spiel sowieso vorbei.
  • Ein anderes Problem, das angesprochen wurde, ist, dass die Identität tatsächlich zwischen mehreren Systemen geteilt wird. Ah! Dies ist ein sehr interessantes Risiko, das genauer betrachtet werden muss.
    Lassen Sie mich damit beginnen, dass es nicht das Tatsächliche ist Identität das ist geteilt, eher das Beweisoder der Authentifizierungsnachweis. Okay, da ein geteiltes Passwort mir den Zugang zu einem anderen System (zB meinem Bankkonto oder Google Mail) ermöglicht, ist dies im Grunde die gleiche Identität, also ist es nur Semantik ... Abgesehen davon es ist nicht. Die Identität wird von jedem System in diesem Szenario getrennt verwaltet (obwohl es ID-Systeme von Drittanbietern geben könnte, z. B. OAuth - immer noch, getrennt von der Identität in diesem System - mehr dazu später).
    Daher besteht der Kernpunkt des Risikos hier darin, dass der Benutzer bereitwillig sein (dasselbe) Passwort in mehrere verschiedene Systeme eingibt - und jetzt kann ich (der Administrator) oder jeder andere Hacker meiner Site Zugang zu den Passwörtern von Tante Erma haben die Atomrakete-Site.

Hmmm.

Scheint dir hier irgendetwas?

Es sollte.

Beginnen wir mit der Tatsache, dass das nukleare Raketensystem geschützt wird nicht meine Verantwortung, Ich baue gerade eine frakkin Familienausflugsstelle (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, der dafür bekannt ist, wiederholt das gleiche Passwort zwischen sicheren und nicht so sicheren Websites zu verwenden) - warum würde ich mich dann darum kümmern, Ihre Website zu hacken? Oder kämpfen Sie mit Ihrer symmetrischen Verschlüsselung? Goshdarnitall, ich kann einfach auflegen meine eigene einfache Website, melden Sie sich an, um SEHR WICHTIGE NACHRICHTEN über alles, was sie wollen, zu erhalten ... Puffo Presto, ich habe ihre Passwörter "gestohlen".

Ja, die Benutzerschulung kommt immer wieder zurück, um uns in die Hienie zu beißen, oder?
Und Sie können nichts dagegen tun ... Selbst wenn Sie ihre Passwörter auf Ihrer Site hashen und alles andere tun sollten, was die TSA denken kann, haben Sie ihr Passwort geschützt NICHT EIN WEISSWenn sie ihre Kennwörter auf jeder Seite, an die sie stoßen, unveränderlich festhalten. Versuchen Sie es nicht einmal.

Anders ausgedrückt, Sie besitzen keine PasswörterAlso hör auf zu versuchen, so zu tun, wie du es tust.

Also, meine lieben Sicherheitsexperten, wie eine alte Dame Wendy fragte: "Wo ist das Risiko?"

Ein paar weitere Punkte als Antwort auf einige der oben genannten Punkte:

  • CWE ist kein Gesetz, keine Verordnung oder sogar ein Standard. Es ist eine Sammlung von gemeinsame Schwächen, d.h. das Gegenteil von "Best Practices".
  • Das Problem der gemeinsamen Identität ist ein tatsächliches Problem, wird aber von den Neinsagern hier falsch verstanden (oder falsch dargestellt). Es ist ein Problem, die Identität an und für sich (!) Zu teilen, NICHT die Passwörter auf Systemen mit geringem Wert zu knacken. Wenn Sie ein Kennwort zwischen einem System mit geringem Wert und einem System mit hohem Wert teilen, ist das Problem bereits vorhanden.
  • Übrigens würde der vorherige Punkt tatsächlich zeigen GEGEN Verwenden von OAuth und dergleichen für diese beiden Systeme mit geringem Wert und die hochwertigen Banksysteme.
  • Ich weiß, es war nur ein Beispiel, aber (leider) sind die FBI-Systeme nicht wirklich am sichersten. Nicht ganz wie die Server Ihrer Katze, aber sie übertreffen auch einige der sichereren Banken nicht.
  • Split-Wissen oder Dual-Control-Verschlüsselung Schlüssel passieren nicht nur im Militär, in der Tat PCI-DSS jetzt erfordert Dies ist im Grunde von allen Händlern, so ist es nicht wirklich so weit draußen (wenn der Wert es rechtfertigt).
  • All jenen, die sich beschweren, dass Fragen wie diese den Beruf des Entwicklers so schlecht aussehen lassen: Antworten wie diese machen den Sicherheitsberuf noch schlimmer. Auch hier ist eine geschäftsorientierte Risikoanalyse erforderlich, sonst machen Sie sich selbst nutzlos. Außerdem falsch liegen.
  • Ich denke, das ist der Grund, warum es keine gute Idee ist, einen normalen Entwickler zu nehmen und mehr Sicherheitsaufgaben auf ihn fallen zu lassen, ohne zu trainieren, anders zu denken und nach den richtigen Kompromissen zu suchen. Nichts für ungut, für diejenigen von euch hier, ich bin dafür - aber mehr Training ist in Ordnung.

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

  • Erklären Sie dem Kunden den richtigen Weg, Dinge zu tun.
  • Wenn er immer noch darauf besteht, erklären Sie mehr, bestehen Sie darauf, argumentieren Sie. Werfen Sie einen Wutanfall, wenn nötig.
  • Erklären Sie ihm das Geschäftsrisiko. Details sind gut, Zahlen sind besser, eine Live-Demo ist normalerweise am besten.
  • Wenn er weiterhin darauf besteht, und stellt gültige Geschäftsgründe dar - es ist Zeit für Sie, einen Urteilsspruch zu machen:
    Ist diese Website niedrig bis gar nicht? Ist es wirklich ein gültiger Geschäftsfall? Ist es gut genug für dich? Gibt es keine anderen Risiken, die Sie in Betracht ziehen können und die aus geschäftlichen Gründen überwiegen? (Und natürlich, ist der Client keine bösartige Seite, aber das ist duh).
    Wenn ja, geh einfach weiter. Es ist nicht die Mühe wert, Reibung und verlorene Nutzung (in dieser hypothetischen Situation), um den notwendigen Prozess in Kraft zu setzen. Jede andere Entscheidung (wiederum in dieser Situation) ist ein schlechter Kompromiss.

Also, unter dem Strich, und eine tatsächliche Antwort - verschlüsseln Sie es mit einem einfachen symmetrischen Algorithmus, schützen Sie den Verschlüsselungsschlüssel mit starken ACLs und vorzugsweise DPAPI oder dergleichen, dokumentieren Sie es und lassen Sie den Client (jemand Senior genug, um diese Entscheidung zu treffen) abmelden es.


25
2018-02-23 15:01