Wie soll ich ethisch Ansatz von Benutzer-Passwort-Speicher für die spätere Klartext abrufen?

https://stackoverflow.com/questions/2283937

21-09-2019
|

Frage

Als ich weiter bauen mehr und mehr websites und web-Anwendungen oft werde ich gefragt, zum speichern von Benutzer-Passwörter in einer Weise, die Sie kann abgerufen werden, wenn/wenn der Benutzer ein Problem (entweder per E-Mail einen link " Kennwort vergessen, gehen Sie durch über das Telefon, etc.) Wenn ich kann, gegen den ich kämpfen erbittert gegen diese Praxis und ich habe eine Menge von "extra" - Programmierung, um das zurücksetzen von Kennwörtern und administrative Unterstützung möglich, ohne die Speicherung Ihrer eigentliche Passwort.

Wenn ich kann nicht kämpfen (oder nicht gewinnen kann), dann habe ich immer codieren Sie das Kennwort in irgendeiner Weise, so dass es zumindest nicht als Klartext gespeichert, in der Datenbank, obwohl ich mir bewusst bin, dass, wenn meine DB gehackt wird, wäre es nicht viel für die Täter zu knacken die Passwörter, so das macht mich unangenehm.

In einer perfekten Welt Leute würden aktualisieren, Kennwörter Häufig und nicht duplizieren Sie Sie auf vielen verschiedenen Seiten—leider kenne ich VIELE Menschen, die die gleiche Arbeit/Zuhause/E-Mail/bank-Passwort, und haben sogar frei, es zu mir, wenn Sie Hilfe benötigen.Ich will nicht derjenige sein, der verantwortlich für Ihre finanziellen Untergang, wenn meine DB-Sicherheits-Verfahren scheitern, aus irgendeinem Grund.

Moralisch und ethisch fühle ich mich verantwortlich für den Schutz der was werden kann, für einige Benutzer, Ihren Lebensunterhalt selbst wenn Sie behandeln Sie es mit viel weniger Respekt.Ich bin sicher, es gibt viele Wege, sich zu nähern, und die Argumente, die für das Salzen von hashes und verschiedene Optionen für die Kodierung aber ist es eine einzige "best practice", wenn Sie haben, um Sie zu speichern?In fast allen Fällen, die ich bin mit PHP und MySQL, wenn das macht keinen Unterschied in der Art und Weise, die ich behandeln soll, die die Besonderheiten.

Zusätzliche Informationen für Bounty

Ich möchte klarstellen, dass ich weiß, das ist nicht etwas, was Sie wollen zu tun habe und dass in den meisten Fällen Weigerung, dies zu tun, ist am besten.Ich bin aber nicht auf der Suche für einen Vortrag über die Vorteile der Einnahme dieser Ansatz ich bin auf der Suche für die besten Schritte zu ergreifen, wenn Sie mit diesem Ansatz.

In einem Hinweis unten ich machte den Punkt, dass Webseiten orientieren sich weitgehend in Richtung der ältere, geistig Behinderte oder sehr junge kann verwirrend werden für die Menschen, wenn Sie gebeten werden, führen Sie einen sicheren Passwort-recovery-routine.Aber wir finden es einfach alltäglich und in diesen Fällen müssen einige Benutzer, die zusätzliche Unterstützung von entweder mit einem service-tech-helfen Sie Ihnen, in das system oder per E-Mail direkt angezeigt, um Sie.

In solchen Systemen die Mortalitätsrate von diesen Demographie konnte humpeln die Anwendung, wenn die Benutzer wurden nicht gegeben, diesen Zugang Unterstützung, so bitte um Antwort mit einem solchen setup in mind.

Vielen Dank an Alle

Dieser hat Spaß gemacht, Frage mit viel Diskussion und ich habe es genossen.Am Ende wählte ich eine Antwort, die sowohl behält die Passwort-Sicherheit (ich will nicht haben, zu halten nur-text-oder erstattungsfähig-Passwörter), sondern macht es auch möglich für die Benutzer-Basis, die ich angegeben einloggen in ein system ohne größere Probleme, die ich gefunden habe, aus der normalen Passwort-Wiederherstellung.

Wie immer gab es über 5 Antworten, die ich haben möchte als korrekt markiert, aus unterschiedlichen Gründen, aber ich hatte die beste zu wählen--alle den rest bekam ein +1.Vielen Dank an alle!

Vielen Dank auch an alle, die in der Stack-community, die abgestimmt haben für diese Frage und/oder markiere es als Favorit.Ich nehme schlagen, 100 bis Stimmen als Kompliment und hoffe, dass diese Diskussion dazu beigetragen hat jemand anderes mit der gleichen Sorge, die ich hatte.

Lösung

Wie wäre es einen anderen Ansatz oder Winkel auf dieses Problem zu nehmen? Fragen Sie, warum wird das Passwort im Klartext sein benötigt: wenn es so, dass der Benutzer das Passwort abrufen können, dann streng genommen Sie nicht wirklich das Passwort abrufen müssen sie gesetzt (sie kann mich nicht erinnern, was es ohnehin ist), können Sie Bedarf, ihnen ein Passwort geben, die sie können .

Denken Sie daran: wenn der Benutzer das Passwort abrufen muss, ist es, weil sie es vergessen haben. In diesem Fall wird ein neues Passwort ist nur so gut wie die alten. Aber einer der Nachteile von gemeinsamen Mechanismen zum Zurücksetzen des Passworts verwendet heute ist, dass die generierten Passwörter in einem Reset-Vorgang erzeugt werden, sind im Allgemeinen eine Reihe von zufälligen Zeichen, so dass sie für den Benutzer schwierig, einfach in richtig eingegeben, es sei denn sie kopieren-n- Einfügen. Das kann ein Problem für weniger versierte Computerbenutzer sein.

Ein Weg, um dieses Problem ist, automatisch generierte Passwörter zu schaffen, die mehr oder weniger Text in natürlicher Sprache. Während natürliche Sprache Saiten nicht die Entropie haben könnten, dass eine Reihe von zufälligen Zeichen der gleichen Länge hat, gibt es nichts, was Ihre automatisch generierte sagt Bedürfnisse Passwort nur 8 (oder 10 oder 12 Zeichen) haben. Holen Sie sich ein hohes Entropie automatisch generierte Passwort durch Zusammen mehr zufälligen Worte Bespannen (läßt einen Raum zwischen ihnen, so dass sie noch erkennbar und typisierbarem von jemandem sind, der lesen kann). Sechs zufällige Worte von unterschiedlicher Länge sind wahrscheinlich einfacher, richtig zu schreiben und mit Vertrauen als 10 zufällige Zeichen, und sie können auch eine höhere Entropie haben. Zum Beispiel würde die Entropie eines 10-Zeichen-Passwort zufällig aus Großbuchstaben, Kleinbuchstaben, Ziffern und Interpunktionszeichen 10 (für eine Gesamtmenge von 72 gültigen Symbole) eine Entropie von 61,7 Bits gezogen. Mit einem Wörterbuch von 7776 Worten (als Diceware Anwendungen), die zufällig für sechs Wort Passwort ausgewählt werden könnte, würde das Passwort eine Entropie von 77,4 Bits hat. Sehen Sie sich die Diceware FAQ für weitere Informationen.

ein Passwort mit etwa 77 Bit Entropie: "zugeben Prosa Flare Tisch akutes Flair"
ein Passwort mit etwa 74 Bit Entropie: "K: & $ R ^ tt ~ QKD"

Ich weiß, dass ich lieber den Begriff eingeben und mit Copy-n-Paste, die Formulierung ist nicht weniger leicht zu bedienen, dass das Passwort entweder, also ohne Verlust gibt. Natürlich, wenn Sie Ihre Webseite (oder was auch immer das Schutzgut ist) braucht nicht 77 Bit Entropie für eine automatisch generierte Passwort ein, erzeugen weniger Wörter (was ich bin sicher, dass Ihre Benutzer würden schätzen).

ich die Argumente verstehen, dass es ein Passwort geschützt Vermögenswerte, die nicht wirklich ein hohes Maß an Wert, so dass die Verletzung eines Passworts nicht das Ende der Welt sein könnte. Zum Beispiel würde ich wahrscheinlich, wenn 80% der Passwörter nicht meinetwegen auf verschiedene Websites verwenden verletzt wurde: alles, was für eine Weile ist es, einen jemand Spamming oder Posting unter meinem Namen passieren könnte. Das wäre nicht so toll, aber es ist nicht, wie sie in mein Bankkonto brechen würden. Doch angesichts der Tatsache, dass viele Menschen das gleiche Passwort für ihre Web-Forum-Sites verwenden, wie sie für ihre Bankkonten (und wahrscheinlich auch die nationalen Sicherheit Datenbanken) zu tun, ich denke, es wäre am besten, auch jene ‚geringer Wert‘ Passwörter als nicht zu handhaben -recoverable.

Andere Tipps

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

Architekt:. für ein Gebäude dieser Größe und Kapazität benötigen Sie Notausgänge hier, hier und hier
. Kunde: Nein, die zu kompliziert und teuer zu warten, ich will keine Seitentüren oder Hintertüren
Architekt:. Sir, Notausgänge nicht optional sind, sind sie verpflichtet, nach dem Brand Code der Stadt
Auftraggeber: Ich bezahle Sie nicht zu streiten. Genau das tun, was ich gefragt habe.

Verlangt der Architekt dann, wie ethisch dieses Gebäude zu bauen, ohne Notausgänge?

In der Bau- und Maschinenbauindustrie, das Gespräch ist wahrscheinlich so enden:

Architekt: Dieses Gebäude kann nicht ohne Notausgänge gebaut werden. Sie können zu jedem anderen lizenzierten professionellen gehen und er wird dir das Gleiche sagen. Ich gehe jetzt; rufen Sie mich zurück, wenn Sie bereit sind zu kooperieren.

Computer-Programmierung kann nicht sein, ein lizenziert Beruf, aber die Leute zu fragen, scheinen oft, warum unser Beruf nicht den gleichen Respekt wie ein Zivil- oder Maschinenbauingenieur bekommt - na ja, suchen Sie nicht weiter. Diese Berufe, wenn handed Müll (oder geradezu gefährlich) Anforderungen, einfach ablehnen. Sie wissen, es ist keine Entschuldigung zu sagen: „Nun, ich habe mein Bestes gegeben, aber er bestand darauf, und ich muss das tun, was er sagt.“ Sie konnten ihre Lizenz für diese Entschuldigung verlieren.

Ich weiß nicht, ob Sie oder Ihre Kunden Teil einer börsennotiertes Unternehmen sind, aber Passwörter in jeder wiederherstellbaren Form zu speichern würde dazu führen Sie verschiedene Arten von Sicherheitsprüfungen an zum Scheitern verurteilt. Die Frage ist nicht, wie schwierig es für einige „Hacker“ sein würde, der den Zugriff auf Ihre Datenbank bekam, um die Passwörter wiederherzustellen. Die große Mehrheit der Sicherheitsbedrohungen sind intern. Was müssen Sie gegen schützen, ist einige verärgerter Mitarbeiter zu Fuß mit allen Passwörter aus und sie an den Meistbietenden zu verkaufen. Mit asymmetrischen Verschlüsselung und den privaten Schlüssel in einer separaten Datenbank gespeichert nichts ist absolut dieses Szenario zu verhindern; Es gibt immer sein werde jemand mit Zugang zum privaten Datenbank, und das ist ein ernsthaftes Sicherheitsrisiko dar.

Es gibt keine ethische oder verantwortliche Weise zu speichern Passwörter in einer gewinnbaren Form. Period.

Sie können das Passwort + ein Salz mit einem öffentlichen Schlüssel verschlüsseln. Für Anmeldungen überprüfen nur, wenn der gespeicherte Wert den Wert aus der Benutzereingabe + Salz berechnet entspricht. Wenn es kommt eine Zeit, wenn das Passwort im Klartext gestellt werden muss, können Sie entschlüsseln manuell oder halbautomatisch mit dem privaten Schlüssel. Der private Schlüssel kann an anderer Stelle gespeichert werden und zusätzlich symmetrisch verschlüsselt werden kann (die eine menschliche Interaktion benötigen das Passwort dann zu entschlüsseln).

Ich denke, dies ist die Art und Weise eigentlich ganz ähnlich ist der Windows-Recovery Agent funktioniert.

Passwörter werden verschlüsselt gespeichert
Die Leute können anmelden, ohne Entschlüsselung Klartext
Passwörter können gestellt werden Klartext, aber nur mit einem privaten Schlüssel, die außerhalb des Systems gespeichert werden können (in einem Banksafe, wenn Sie wollen).

Geben Sie nicht auf. Die Waffe, die Sie verwenden können, um Ihre Kunden zu überzeugen ist Nichtabstreitbarkeit. Wenn Sie Benutzer-Passwörter über einen beliebigen Mechanismus rekonstruieren können, haben Sie gegeben ihre Kunden eine juristische Unbestreitbarkeit Mechanismus und sie können jede Transaktion ablehnen, die auf diesem Passwort ab, weil es keine Möglichkeit gibt, kann der Lieferant nachweisen, dass sie haben nicht das Passwort rekonstruieren und die Transaktion durch selbst setzen. Wenn Passwörter korrekt als Verdauansätzen gespeichert sind und nicht verschlüsselter Text, das ist unmöglich, ergo entweder das Ende-Client der Transaktion selbst ausgeführt oder verletzt seine Sorgfaltspflicht w.r.t. das Passwort. In jedem Fall, dass die Haftung direkt mit ihm verläßt. Ich habe über Fälle gearbeitet, wo das auf Hunderte von Millionen Dollar belaufen. Nicht etwas, was Sie wollen etwas falsch laufen.

Sie können nicht ethisch speichern Passwörter für die späteren Klartext Retrieval. So einfach ist das. Auch Jon Skeet kann nicht ethisch Passwörter für den Abruf später Klartext speichern. Wenn die Benutzer-Passwörter im Klartext abrufen kann so oder so, dann möglicherweise so kann auch ein Hacker, der eine Sicherheitslücke im Code findet. Und das ist nicht nur ein Passwort des Benutzers beeinträchtigt wird, aber alle.

Wenn Sie Ihre Kunden ein Problem damit haben, ihnen sagen, dass Passwörter wiedergewinnbar Speicherung des Gesetzes ist gegen. Hier in Großbritannien auf jeden Fall, die Data Protection Act 1998 (insbesondere Anhang 1, Teil II, Ziffer 9) erfordert die Datenverarbeitung Verantwortlichen die entsprechenden technischen Maßnahmen zu verwenden, um persönliche Daten geheim zu halten, unter Berücksichtigung unter anderem der Schaden, der kompromittiert wurden verursacht werden könnte, wenn die Daten -, die für Benutzer, die Aktie Passwörter zwischen Standorten erheblich sein könnten. Wenn sie immer noch Schwierigkeiten haben, grokking die Tatsache, dass es ein Problem ist, zeigen Sie sie auf einige reale Beispiele, wie dieses .

Der einfachste Weg, um Benutzern erlauben eine Anmeldung wiederherstellen zu E-Mail ihnen eine einmalige Verbindung, dass Protokolle sie automatisch und bringt sie direkt auf eine Seite, wo sie ein neues Passwort auswählen können. Erstellen Sie einen Prototyp und zeigen es in Aktion zu ihnen.

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

Update: Wir beginnen nun Klagen und Anklagen gegen Unternehmen zu sehen, die nicht ihre Passwörter der Benutzer ordnungsgemäß sichern. Beispiel: LinkedIn Slapped mit $ 5.000.000 Klage Klasse; Sony bestraft £ 250.000 über PlayStation Daten hacken . Wenn ich mich richtig erinnere, wurde LinkedIn seine Passwörter der Benutzer tatsächlich zu verschlüsseln, aber die Verschlüsselung es wurde mit war zu schwach, um wirksam zu sein.

Nach diesem Teil zu lesen:

In einer Anmerkung unter ich den Punkt gemacht, dass   Websites ausgerichtet weitgehend in Richtung der   ältere Menschen, geistig behinderten oder sehr   Junge kann für Menschen, verwirrend   wenn sie gefragt, ein ausführen   sichere Passwort-Recovery-Routine.   Obwohl wir finden es einfach und   banale in den Fällen, einige Benutzer benötigen   die zusätzliche Unterstützung von entweder mit   eine Service-Tech-Hilfe, um sie in die   System oder mit ihm per E-Mail / displayed   direkt an sie.

Bei solchen Systemen die Ausfallrate   Von dieser Demografie könnte humpeln   die Anwendung, wenn die Benutzer nicht waren   Diese Zugriffsebene Unterstützung gegeben,   so bitte Antwort mit einer solchen Einrichtung in   Geist.

Ich frage mich nach links, wenn eine dieser Anforderungen ein abrufbares Passwort-System beauftragen. Zum Beispiel: Tante Mabel ruft und sagt: „Ihr Internet-Programm funktioniert nicht, ich weiß es nicht vergessen“. „OK“, sagt der Kundendienst Drohne „lassen Sie mich ein paar Details überprüfen und dann werde ich geben Sie ein neues Passwort . Wenn Sie das nächste Login werden Sie gefragt, ob Sie das Kennwort behalten möchten oder ändern sie etwas können Sie leichter merken. "

Dann wird das System einrichten wissen, wann ein Passwort-Reset passiert ist und zeigt ein „möchten Sie das neue Passwort behalten oder einen neuen wählen“ angezeigt.

Wie ist die schlimmer für die weniger PC-gebildeter als ihr altes Passwort gesagt werden? Und während des Kundenservice Person zu Schaden kommen kann, die Datenbank selbst ist viel sicherer, falls es verletzt wird.

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

Michael Brooks war ziemlich lautstark über CWE-257 - die Tatsache, dass das, was Methode Sie verwenden, können Sie (der Administrator) kann immer noch das Passwort erholen. So wie über diese Optionen:

Verschlüsseln das Passwort mit jemand anderes öffentliche Schlüssel - einige externe Behörde. Auf diese Weise können Sie es nicht persönlich rekonstruieren, und der Benutzer wird auf diese externe Stelle zu gehen und fragen, ihr Passwort haben gewonnen.
Verschlüsseln Sie das Kennwort einen Schlüssel aus einem zweiten Passwort generiert. Haben diese Verschlüsselung clientseitige und nie übertragen sie im klaren zu dem Server. Dann zu erholen, tun, um die Entschlüsselung Client-Seite wieder durch erneute Generierung des Schlüssels aus ihrer Eingabe. Zwar wird dieser Ansatz im Grunde ein zweites Passwort, aber man kann sie immer, es zu schreiben sagen unten, oder die alten Sicherheitsfrage Ansatz.

Ich denke, 1. ist die bessere Wahl, weil es Ihnen ermöglicht, jemanden zu benennen innerhalb des Unternehmens des Kunden, den privaten Schlüssel zu halten. Stellen Sie sicher, dass sie den Schlüssel selbst erzeugen, und speichern Sie es mit Anweisungen an einem sicheren etc. Sie auch Sicherheit durch die Wahl nur verschlüsseln könnten hinzufügen und bestimmte Zeichen aus dem Passwort an den internen Dritten liefern, so dass sie das Passwort zu erraten knacken würden es. Die Versorgung dieser Zeichen an den Benutzer, werden sie wahrscheinlich daran erinnern, was es war!

Es ist für den Benutzer als Antwort auf diese Frage eine Menge Diskussionen über Sicherheitsbedenken, aber ich möchte eine Erwähnung von Vorteilen hinzuzufügen. Bisher habe ich nicht gesehen ein legitimer Nutzen erwähnt für einen behebbaren Passwort auf dem System gespeichert sind. Bedenken Sie:

Hat der Benutzer profitiert von ihrem Passwort, um sie per E-Mail zu haben? Nein, sie erhalten mehr Nutzen aus einem einmaligen Gebrauch Passwort-Reset-Link, die hoffentlich erlauben würde ihnen ein Passwort wählen sie wird erinnern.
Hat der Benutzer profitiert von ihrem Passwort auf dem Bildschirm angezeigt zu haben? Nein, aus dem gleichen Grund wie oben; sie sollten ein neues Passwort wählen.
Hat der Benutzer profitiert von einer Unterstützung Person, die spricht das Passwort für den Benutzer? Nein; wenn die Unterstützung Person die Benutzeranforderung für ihr Passwort hält wieder, wie korrekt authentifiziert, es ist mehr zum Nutzen des Benutzers werden ein neues Passwort und die Möglichkeit, es zu ändern. Plus, Telefon-Support ist teurer als automatisiertes Passwort-Resets, so das Unternehmen auch nicht profitieren.

Es scheint, die einzigen, die aus wiederherstellbaren Passwörter sind diejenigen mit böswilliger Absicht oder Unterstützer der schlechten APIs profitieren können, die von Drittanbietern Passwort Austausch erfordern (bitte nicht die Verwendung APIs überhaupt!). Vielleicht können Sie Ihr Argument gewinnen, indem sie ehrlich zu Ihren Kunden die besagt, dass das Unternehmen keine Vorteile gewinnt und nur Verbindlichkeiten durch die erzielbaren Passwörter zu speichern .

zwischen den Zeilen dieser Art von Anfragen Lese, werden Sie feststellen, dass Ihre Kunden wahrscheinlich nicht verstehen, oder eigentlich gar kümmern, wie Passwörter verwaltet werden. Was sie wirklich wollen, ist ein Authentifizierungssystem , die nicht so hart für ihre Benutzer. Also zusätzlich zu ihnen zu sagen, wie sie eigentlich gar nicht wiederherstellbare Passwörter wollen, sollten Sie diese Möglichkeiten bieten der Authentifizierungsprozess weniger schmerzhaft zu machen, vor allem, wenn Sie nicht brauchen, um die schweren Sicherheitsstufen von, sagen wir, eine Bank:

Lassen Sie die Benutzer ihre E-Mail-Adresse für ihren Benutzernamen verwenden. Ich habe unzählige Fälle, in denen der Benutzer seinen Benutzernamen vergisst, aber nur wenige ihre E-Mail-Adresse vergessen.
Angebot OpenID und lassen Sie ein Drittanbieter zahlen für die Kosten der Benutzer Vergesslichkeit.
zu den Kennworteinschränkungen nachzulassen. Ich bin sicher, wir haben alle unglaublich geärgert, wenn einige Website nicht unterstützt Ihr bevorzugtes Passwort erlauben wegen nutzlos Anforderungen wie „Sie keine Sonderzeichen verwenden können“ oder „Ihr Passwort ist zu lang“ oder „Ihr Passwort muss beginnen mit einem Brief.“ Auch, wenn Benutzerfreundlichkeit eine größere Sorge als Passwortstärke ist, könnten Sie lösen auch die nicht dumm Anforderungen durch kürzere Passwörter zulassen oder nicht eine Mischung aus Charakterklassen erfordern. Mit gelockerten Einschränkungen, werden die Nutzer mehr wahrscheinlich ein Passwort verwenden sie nicht vergessen werden.
verfallen nicht Kennwörter.
Lassen Sie den Benutzer ein altes Passwort wieder zu verwenden.
Lassen Sie die Benutzer ihre eigenen Passwort-Reset-Frage wählen.

Aber wenn Sie aus irgendeinem Grund (und Sie uns bitte sagen, der Grund) wirklich, wirklich, wirklich müssen in der Lage sein einen behebbaren Passwort haben, können Sie den Benutzer schützen vor möglicherweise ihren anderen zu beeinträchtigen Online-Konten von ihnen ein nicht-passwortbasierte Authentifizierungssystem zu geben. Weil die Menschen bereits vertraut sind mit Benutzername / Passwort-Systeme und sie sind eine gut ausgeübt Lösung, wäre dies das letzte Mittel sein, aber es gibt sicherlich viele kreative Alternativen zu Passwörtern:

Lassen Sie den Benutzer wählen, eine numerische PIN, vorzugsweise nicht 4-stelliges, und vorzugsweise nur dann, wenn Brute-Force-Versuche sind geschützt gegen.
Haben der Benutzer wählen, eine Frage mit einer kurzen Antwort, die nur wissen, dass sie die Antwort auf, wird sich nie ändern, werden sie immer daran denken, und es macht ihnen nichts andere Leute zu erfahren.
Haben der Benutzer einen Benutzernamen eingeben und dann ziehen eine leicht zu merkende Form mit ausreichend permutagen gegen Erraten (siehe dieses geschickten Foto , wie das G1 zu schützen tut dies zum Entriegeln das Telefon).
für eine Website für Kinder, können Sie die automatische Erzeugung eines Fuzzy-Kreatur, basierend auf dem Benutzernamen (Art wie ein Identicon) und den Benutzer auffordern, die Kreatur einen geheimen Namen zu geben. Sie können dann aufgefordert, der Kreatur geheimen Namen eingeben, um sich einzuloggen.

Nach dem Kommentar, den ich auf die Frage gestellt:
Ein wichtiger Punkt wurde von fast jeder sehr beschönigt ... Meine erste Reaktion war sehr ähnlich @ Michael Brooks, bis ich erkannte, wie @stefanw, dass das Problem hier ist, Anforderungen gebrochen, aber diese sind, was sie sind.
Aber dann, es fiel mir ein, dass vielleicht nicht einmal der Fall sein! Der fehlende Punkt hier ist der unausgesprochene Wert des Vermögens der Anwendung. Einfach gesagt, für einen niedrigen Wert-System, ein vollständig sicheren Authentifizierungsmechanismus, mit all der Prozess beteiligt sind, würde zu viel des Guten, und die falsch Sicherheit Wahl.
Offensichtlich für eine Bank, die „best practices“ sind ein Muss, und es gibt keine Möglichkeit, ethisch CWE-257 zu verletzen. Aber es ist einfach von geringen Wert Systemen zu denken, wo es einfach nicht wert (aber ein einfaches Passwort ist nach wie vor erforderlich).

Es ist wichtig, sich daran zu erinnern, wahre Sicherheit Know-how ist angemessen Kompromissen bei der Suche, nicht in dogmatisch die "Best Practices" speienden, dass jemand online lesen kann.

Als solche, schlage ich eine andere Lösung:
Je nach dem Wert des Systems und NUR WENN ist das System in geeignete Weise mit geringen Wert ohne „teuer“ Vermögenswert (die Identität selbst eingeschlossen), und gibt es gültig Business-Anforderungen, die richtige Prozess unmöglich (oder ausreichend schwierig / teuer), machen und der Kunde aller Vorbehalte aufmerksam gemacht wird ...
Dann könnte es sinnvoll sein, einfach reversible Verschlüsselung ermöglichen, ohne speziellen Reifen springen durch.
Ich bin zu stoppen nur kurz nicht zu sagen mit Verschlüsselung überhaupt zu stören, weil es sehr einfach / billig zu implementieren ist (auch passible Key-Management unter Berücksichtigung), und es hat einig Schutz bieten (mehr als die Kosten ihrer Durchführung). Auch sein lohnt ein Blick auf, wie der Benutzer mit dem ursprünglichen Kennwort angeben, ob per E-Mail, die Anzeige auf dem Bildschirm usw.
Da hier die Annahme, dass der Wert des gestohlenen Passwort (auch in Aggregat) recht niedrig ist, kann jeder dieser Lösungen gültig sein.

Da gibt es eine lebhafte Diskussion ist im Gang, tatsächlich mehrere lebhaften Diskussionen in den verschiedenen Beiträgen und seperate Kommentar Themen werde ich einige Präzisierungen und reagiert auf einige der sehr guten Seiten hinzufügen, die an anderer Stelle hier angesprochen wurden.

Um zu beginnen, ich denke, es ist jedem klar ist hier, dass das Original-Passwort des Benutzers Lassen abgerufen werden, ist eine schlechte Praxis, und in der Regel keine gute Idee. Das ist nicht bei allen strittigen ...
Des Weiteren werde ich, dass in vielen, ja MOST, Situationen betonen - es ist wirklich falsch, auch Foul, 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 zu tun so in der korrekteste Art und Weise der Situation angemessen .

Jetzt, da @Thomas, @sfussenegger und einige andere erwähnt, ist der einzig richtige Weg, diese Frage zu beantworten, ist eine gründliche Risikoanalyse zu tun von einem bestimmten (oder hypothetische) Situation zu verstehen, was auf dem Spiel steht, wie viel es wert ist zu schützen, und was andere Milderungen im Spiel ist, dass der Schutz zu leisten.
Nein, es ist kein Modewort, das ist eine der grundlegenden, wichtigsten Werkzeuge für ein Echt Live-Sicherheitsexperten. Best Practices sind gut bis zu einem Punkt (in der Regel als Richtlinien für den unerfahrenen und die Hacks), nachdem dieser Punkt differenzierten Risikoanalyse übernimmt.

Y'know, es ist lustig - ich hielt mich immer einer der Sicherheitsfanatiker, und irgendwie bin ich auf der gegenüberliegenden Seite dieser sogenannten „Sicherheitsexperten“ ... Nun, die Wahrheit ist - denn ich bin ein Fanatiker, und ein tatsächlicher realer Sicherheitsexperte - ich glaube nicht, „Best Practice“ Dogma (oder CWEs) in speienden OHNEdass alle wichtigen Risikoanalyse .
„Passen Sie die Sicherheit Eiferer, das schnell ist alles in ihrem Werkzeuggürtel anzuwenden, ohne zu wissen, was die eigentliche Frage ist, sie verteidigen gegen. Mehr Sicherheit nicht unbedingt gleichzusetzen gute Sicherheit.“
Risikoanalyse und wahre Sicherheit Fanatiker würden deuten auf einen intelligentere, Wert / Risiko-basierten Kompromiss, basierend auf Risiko, möglichen Verlust, mögliche Bedrohungen, ergänzende mitigations, etc. Jeden „Security Expert“, die sie nicht Punkt auf einem soliden Risikoanalyse als die Grundlage für ihre Empfehlungen oder logische Kompromissen unterstützen, sondern statt dessen Ausguss Dogma und CWEs, ohne auch nur zu verstehen, wie zur Durchführung einer Risikoanalyse, sind nichts als Sicherheit Hacks und ihre Expertise ist nicht wert, das Toilettenpapier sie es gedruckt bevorzugen würde.

Ja, das ist, wie wir die Lächerlichkeit bekommen, die Flughafensicherheit ist.

Aber bevor wir über die entsprechenden Vor- und Nachteile sprechen in dieser Situation zu machen, lassen Sie uns einen Blick auf die offensichtlichen Risiken (offensichtlich, weil wir alle Informationen Hintergrund nicht haben zu dieser Situation sind wir alle Hypothetisieren - da die Frage, ist das, was könnte es hypothetische Situation ...)
Lassen Sie sich ein LOW-VALUE-System übernehmen, noch nicht so trival, dass es den Zugang der Öffentlichkeit ist - das System Eigentümer will lässig Identitätswechsel verhindern, noch „hoch“ Sicherheit ist nicht so im Vordergrund wie Benutzerfreundlichkeit. (Ja, es ist ein legitimer Kompromiss das Risiko zu akzeptieren, dass jede kompetente Skript-Kiddie der Website hacken ... Bitte warten, ist nicht APT in der Mode jetzt ...?)
Nur zum Beispiel, sagen sie, ich bin eine einfache Website für ein großes Familientreffen arrangieren, so dass jeder zu einem Brainstorming auf, wo wir in diesem Jahr auf unserem Camping-Ausflug gehen wollen. Ich bin weniger besorgt über einige anonyme Hacker oder sogar Cousin Fred in wiederholten Vorschläge Quetschen zum Lake Wantanamanabikiliki zurück zu gehen, wie ich bin über Tante Erma nicht logon in der Lage, wenn sie ihn braucht. Nun, Tante Erma, einen Kernphysiker zu sein, ist nicht sehr gut erinnern, Passwörter oder sogar mit dem Computer überhaupt mit ... Also ich alle Reibung möglich, sie entfernen möge. Auch hier bin besorgt ich nicht über Hacks, ich nicht nur dumme Fehler der falschen Login wollen - ich wissen will, wer kommt, und was sie wollen.

Wie auch immer.
Also, was sind unsere Risiken hier, wenn wir symmetrisch verschlüsseln Passwörter, stattdessen eine Einweg-Hash zu verwenden?

Impersonating Benutzer? Nein, ich habe bereits akzeptiert, dass das Risiko, nicht interessant.
Evil Administrator? Na ja, vielleicht ... Aber auch hier ist mir egal, wenn jemand einen anderen Benutzer ausgeben kann, intern oder nicht ... und sowieso ein böswilliger admin Gonna Ihr Passwort bekommen egal, was - wenn Ihr Admin ist weg schlecht, ist das Spiel vorbei sowieso.
Ein weiteres Problem, das ausgelöst hat, so wird die Identität tatsächlich mehrere Systeme verteilt. Ah! Dies ist ein sehr interessantes Risiko, die einen genaueren Blick erfordert.
Lassen Sie mich zunächst mit der Behauptung, dass es nicht die tatsächlichen ist Identität das ist geteilt, sondern der Beweis , oder der Authentifizierungsnachweis. Okay, da ein gemeinsames Passwort wird mich effektiv Eingang erlauben auf ein anderes System (sagen wir, mein Bankkonto oder gmail), ist dies effektiv die gleiche Identität, so dass es nur Semantik ist ... Abgesehen davon, dass es ist nicht . Identität verwaltet werden separat von jedem System, in diesem Szenario (obwohl es vielleicht Dritte ID-Systeme, wie OAuth sein - nach wie vor, sein getrennt von der Identität in diesem System - dazu später mehr).
Als solche hier der Kern Punkt Risiko ist, dass der Benutzer sein (gleiche) Passwort in mehrere verschiedene Systeme bereitwillig Eingang - und jetzt, ich (der admin) oder andere Hacker meiner Website Zugang zu Tante Erma Passwörter haben für die Atomraketenbasis.

Hmmm.

Hat hier irgendetwas Sie scheinen aus?

Es sollte.

Beginnen wir mit der Tatsache, dass die Atomraketen-System zu schützen, ist nicht meine Verantwortung , ich bin nur building eine frakkin Familienausflug Website (für meine Familie). Wessen Aufgabe ist es? Umm ... Wie über die Atomraketen-System? Duh.
Zweitens, wenn ich wollte, dass jemand das Passwort (jemand, der immer wieder bekannt ist das gleiche Passwort zwischen sicheren Websites zu verwenden, und nicht so sicher sind) stehlen - warum sollte ich Hacking Ihrer Website die Mühe machen? Oder kämpft mit Ihrer symmetrischen Verschlüsselung? Goshdarnitall, ich kann nur in Aufmachungen meine eigene einfache Website haben die Nutzer registrieren zu VERY IMPORTANT NEWS erhalten über das, was sie wollen ... Puffo Presto, ich „stahl“, ihre Passwörter.

Ja, Benutzerschulung immer kommt zurück, um uns in der hienie zu beißen, nicht wahr?
Und es gibt nichts, was man dagegen tun kann ... Auch wenn Sie Hash waren, ihre Passwörter auf Ihrer Website, und tun alles, was das TSA denken kann, hinzugefügt Schutz Sie ihr Passwort keinen Deut , wenn sie gehen, wahllos zu halten, ihre Passwörter in jede Website stecken in sie stoßen. Sie nicht einmal die Mühe zu versuchen.

Um es anders auszudrücken, Sie besitzen ihre Kennwörter nicht , so aufhören zu versuchen, zu handeln, wie Sie tun.

So, mein Lieber Sicherheitsexperte, als eine alte Dame, die für Wendys fragen: „Wo ist das Risiko?“

Noch ein paar Punkte in der Antwort auf einige Fragen oben angehoben:

CWE ist kein Gesetz oder Verordnung, oder sogar ein Standard. Es ist eine Sammlung von gemeinsamen Schwächen , das heißt die Umkehrung von "Best Practices".
Die Frage der gemeinsamen Identität ist ein tatsächliches Problem, aber falsch verstanden (oder falsch dargestellt) von den Pessimisten hier. Es ist eine Frage der Aufteilung die Identität in mich selbst (!), Nicht um die Passwörter auf niedrigen Wert Systeme zu knacken. Wenn Sie ein Passwort zwischen einem Low-Wert und einem hochwertigen System zu teilen, ist das Problem schon da!
Durch den von dem vorherigen Punkt würde tatsächlich Punkt GEGEN mit OAuth und dergleichen sowohl für diese Low-Wert-Systeme und die hochwertigen Bankensysteme.
Ich weiß, es war nur ein Beispiel, aber (leider) die FBI-Systeme sind nicht wirklich die gesichert herum. Nicht ganz wie Sie Ihre Katze Blog-Servern, aber noch haben sie einige der sichereren Banken übertreffen.
Split Wissen oder Dual Kontrolle von Verschlüsselungsschlüsseln nicht gerade geschehen im Militär, in der Tat PCI-DSS jetzt erfordert diese von grundsätzlich alle Händlern, so dass sie nicht wirklich so weit da draußen mehr (Wenn der Wert rechtfertigt).
Für alle diejenigen, die diese Fragen wie diese beklagen sind, was das Aussehen Entwickler Beruf macht so schlecht: es ist Antworten wie diejenigen, die die Sicherheit Beruf Blick noch schlimmer machen. Auch hier ist geschäftsorientierte Risikoanalyse, was erforderlich ist, sonst machen Sie sich nutzlos. Neben falsch zu sein.
Ich denke, das ist, warum es nicht eine gute Idee, nur einen regelmäßigen Entwickler nehmen und mehr Sicherheit Verantwortung auf ihn fallen, ohne Ausbildung, anders zu denken, und für die richtigen Kompromisse zu suchen. Nichts für ungut, zu denen von Ihnen hier, ich bin für sie - aber mehr Training ist, um

Puh. Was für eine lange Post ...
Aber zu beantworten Ihre ursprüngliche Frage, @Shane:

Erklären Sie dem Kunden den richtigen Weg, Dinge zu tun.
Wenn er noch darauf besteht, erklären einige mehr, darauf bestehen, argumentieren. Werfen Sie einen Wutanfall, wenn nötig.
Erklären Sie das unternehmerische Risiko zu ihm. Details sind gut, Zahlen sind besser, eine Live-Demo ist in der Regel am besten.
WENN ER besteht darauf, STILL und präsentiert gültigen geschäftlichen Gründen - es ist Zeit für Sie ein Urteil Anruf zu tun:
Ist diese Seite Low-to-no-Wert? Ist es wirklich ein gültiges Business Case? Ist es gut genug für dich? Gibt es keine anderen Risiken können Sie prüfen, die gültige geschäftlichen Gründen aufwiegen? (Und natürlich ist der Kunde nicht eine bösartige Website, aber das ist duh).
Wenn ja, gehen Sie einfach nach rechts weiter. Es ist nicht die Mühe wert, Reibung und verlorene Nutzung (in dieser hypothetischen Situation)den notwendigen Prozess in Stelle zu setzen. Jede andere Entscheidung (auch hier in dieser Situation) ist ein schlechter Kompromiss.

Also, unterm Strich, und eine tatsächliche Antwort - encrypt es mit einem einfachen symmetrischen Algorithmus, zum Schutz den Verschlüsselungsschlüssels mit starken ACLs und vorzugsweise DPAPI oder dergleichen, Dokument, um es und haben den Client (jemand Senioren genug, um diese Entscheidung zu treffen) abzeichnen auf sich.

Wie über eine Zwischenstation?

Speichern Sie die Passwörter mit einer starken Verschlüsselung und nicht zurücksetzt ermöglichen.

Statt Zurücksetzen von Kennwörtern ermöglichen das Senden eines Einmalpasswort (die als geändert werden muss, sobald die erste Anmeldung erfolgt). Lassen Sie den Benutzer dann ändern, was auch immer sie wollen Passwort (die vorherigen, wenn sie wählen).

Sie können „verkaufen“ dies als sicheren Mechanismus für das Zurücksetzen von Passwörtern.

Die einzige Möglichkeit, ein Benutzer zu ermöglichen, ihr ursprüngliches Passwort zu erhalten, ist auf verschlüsselt es mit dem eigenen öffentlichen Schlüssel des Benutzers. Nur der Benutzer kann dann entschlüsselt ihr Passwort ein.

So werden die Schritte wäre:

User-Register auf Ihrer Website (über SSL natürlich) ohne noch ein Passwort festlegen. Melden sie automatisch oder ein temporäres Passwort.
Sie bieten ihren öffentlichen PGP-Schlüssel für zukünftige Kennwortwieder speichern.
Sie ihren öffentlichen PGP-Schlüssel laden.
Sie sie bitten, ein neues Passwort zu setzen.
Sie tragen vor, ihr Passwort ein.
Sie haben die Passwort-Hash den besten Passwort-Hashing-Algorithmus zur Verfügung (z bcrypt) verwendet wird. Verwenden Sie diese Option, wenn die nächste Login-Validierung.
Sie verschlüsseln das Passwort mit dem öffentlichen Schlüssel, und speichern Sie das separat.

Sollte der Benutzer dann für ihr Passwort fragen, antworten Sie mit dem verschlüsselten (nicht gehasht) Passwort. Wenn der Benutzer nicht in der Lage sein will ihr Passwort in Zukunft abgerufen werden (würde sie nur in der Lage sein, es zu einer service erzeugt ein Zurücksetzen), die Schritte 3 und 7 können übersprungen werden.

Ich denke, die wirkliche Frage, die Sie sich stellen sollten, ist: ‚Wie kann ich davon zu überzeugen, die Menschen besser sein‘

Ich habe das gleiche Problem. Und auf die gleiche Weise denke ich immer, dass jemand mein System hacken, es ist nicht eine Frage des „ob“, sondern „wann“.

Also, wenn ich muß eine Website zu tun, dass Bedarf eine behebbaren vertraulichen Informationen zu speichern, wie eine Kreditkarte oder ein Passwort, was ich tue, es ist:

verschlüsseln mit: openssl_encrypt (string $ data, string $ Methode, string $ password)
- PHP-Handbuch .
Daten arg :
- die sensible Informationen (zum Beispiel das Benutzerpasswort)
- serialize falls erforderlich, zum Beispiel wenn die Information eine Reihe von Daten, wie mehrere sensible Informationen
Passwort arg : Verwenden Sie eine Information, dass nur der Benutzer wissen, wie:
- der Benutzer Nummernschild
- Sozialversicherungsnummer
- Benutzertelefonnummer
- der Benutzer Mutter Name
- eine zufällige Zeichenfolge sended per E-Mail und / oder per SMS an Registerzeit
Methode arg :
- Wählen Sie ein Verschlüsselungsverfahren, wie "aes-256-cbc"
NIE speichert die verwendeten Informationen in dem "password" Argument an Datenbank (oder was auch immer in dem System)

Bei Bedarf dieser Daten retrive nur die „openssl_decrypt ()“ Funktion verwenden und bitten Sie den Benutzer für die Antwort. Z. B .: "Ihr Passwort Antwort auf die Frage erhalten:? Was ist Ihre Handy-Nummer"

PS 1 : nie in der Datenbank gespeichert, um ein Datum als Passwort verwenden. Wenn Sie den Benutzer Handy-Nummer speichern müssen, dann nie diese Informationen benutzen, um die Daten zu kodieren. Immer eine Information verwenden, dass nur der Benutzer wissen oder dass es schwer ist, jemanden nicht relativ bekannt.

PS 2 : für Kreditkarteninformationen, wie "einem Klick kaufen", was ich tue, ist das Login-Passwort verwenden. Dieses Passwort wird in der Datenbank (SHA1, MD5 usw.) gehasht, aber bei der Anmeldung speichere ich das Klartext-Passwort in der Sitzung oder in einem nicht-persistent (das heißt im Speicher) sicheres Cookie. Diese Ebene Passwort nie in der Datenbank zu bleiben, in der Tat ist es immer in Erinnerung, zerstört am Ende des Abschnitts bleiben. Wenn der Benutzer klicken Sie auf „einem Klick kaufen“ dieses Passwort verwenden Sie die Taste System. Wenn der Benutzer mit einem Dienst in wie Facebook angemeldet wurde, twitter, etc., dann prompt ich das Passwort wieder auf dem Kauf Zeit (ok, es ist nicht ein vollständig „auf Klick“) oder dann einige Daten des Dienstes verwenden, die Benutzer-Anmeldung verwendet (wie die Facebook-ID).

Sichern von Anmeldeinformationen ist nicht eine binäre operation:sicher/nicht sicher.Sicherheit ist das Risiko-Bewertung und ist gemessen auf einem Kontinuum.Sicherheits-Fanatiker hassen, so zu denken, aber die hässliche Wahrheit ist, dass nichts absolut sicher.Hash-Passwörter mit strenge Passwort-Anforderungen, DNA-Proben, - und Netzhaut-scans sind sicherer, aber auf Kosten der Entwicklung und Benutzer Erfahrung.Klartext-Passwörter sind weit weniger sicher ist, aber es ist billiger zu implementieren (aber vermieden werden sollte).Am Ende des Tages kommt es zu einer Kosten - /nutzen-Analyse einer Verletzung.Sie implementieren die Sicherheit auf der Grundlage der Wert der Daten, die gesichert und seine Zeit-Wert.

Was ist die Kosten von jemandem das Passwort raus in die wildnis?Was ist die Kosten der Imitation, die in dem gegebenen system?Zu den FBI-Computern, die Kosten konnten immens sein.Bob ist ein-aus-fünf-Seiten-website, die Kosten können vernachlässigbar sein.Eine professionelle bietet Optionen, um Ihre Kunden und die, wenn es um Sicherheit geht, legt die Vorteile und Risiken einer Umsetzung.Das ist doppelt so, wenn der client anfordert, etwas, das könnte ein Risiko darstellen, da andernfalls zu beachten Industrie-standards.Wenn ein Kunde verlangt ausdrücklich eine zwei-Wege-Verschlüsselung, würde ich sicherstellen, dass Sie dokumentieren Ihre Einwände, aber das sollte Sie nicht davon abhalten, die Umsetzung in der beste Weg, wissen Sie.Am Ende des Tages, es ist der client, die Geld von.Ja, Sie sollte push für die Verwendung von Einweg-hashes aber zu sagen, dass ist absolut die einzige Wahl, und alles, was unmoralisch ist, ist völliger Unsinn.

Falls Sie die Speicherung von Passwörtern mit zwei-Wege-Verschlüsselung, Sicherheit kommt alles darauf an, das Schlüssel-management.Windows stellt Mechanismen zum einschränken des Zugriffs auf Zertifikate, private Schlüssel zu administrativen Konten und Passwörter.Wenn Sie hosting auf anderen Plattform ist, würden Sie brauchen, um zu sehen, welche Optionen verfügbar sind, auf denen.Wie andere vorgeschlagen haben, die Sie verwenden können, asymmetrische Verschlüsselung.

Es gibt kein Recht (weder das Datenschutzgesetz in Großbritannien), von denen ich bin mir bewusst, dass ausdrücklich, dass Passwörter gespeichert werden müssen, mit one-way-hashes.Die einzige Voraussetzung ist, in eines dieser Gesetze ist einfach, dass angemessenen Schritte für die Sicherheit.Wenn der Zugang zu der Datenbank ist beschränkt, auch Klartext-Passwörter zu qualifizieren, die rechtlich unter solchen Beschränkung.

Dies gilt jedoch ans Licht bringen ein mehr Aspekt:gesetzliche Vorrang.Wenn die gesetzlichen Vorrang schlägt vor, dass Sie verwenden müssen one-way-hashes angesichts der Branche, in der Ihr system gebaut wird, dann ist das völlig anders.Das ist die Munition, die Sie verwenden, überzeugen Sie Ihre Kunden.Abgesehen, dass der beste Vorschlag, um eine angemessene Risikobewertung dokumentieren Sie Ihre Einwände und implementieren das system auf sicherste Art und Weise können Sie bestimmten Anforderungen des Kunden.

Machen Sie die Antwort auf die Sicherheitsfrage des Benutzers einen Teil des Verschlüsselungsschlüssels, und nicht speichern Sie die Sicherheitsfrage Antwort als Klartext (hash, dass statt)

I Multiple-Faktor-Authentifizierungssysteme für ein Leben implementieren, so dass für mich ist es natürlich, zu denken, dass Sie entweder das Kennwort zurückzusetzen oder rekonstruieren kann, während vorübergehend ein weniger Faktors für den Benutzer zu authentifizieren nur den Reset / Erholung Workflow. Insbesondere die Verwendung von OTP (One-Time-Passwörtern), da einige der zusätzlichen Faktoren, mildert viel von dem Risiko, wenn das Zeitfenster ist die Abkürzung für den vorgeschlagenen Workflow. Wir haben Generatoren Software OTP implementiert für Smartphones mit großem Erfolg (die meisten Benutzer bereits mit sich selbst den ganzen Tag tragen). Vor klagt einen kommerziellen Stecker erscheinen, was ich sagen will ist, dass wir die Risiken, die zu halten Passwörter leicht auffindbar oder rücksetzbar können senken, wenn sie verwendete nicht der einzige Faktor ist einen Benutzer zu authentifizieren. Ich gebe zu, dass die Situation unter Websites Szenarien für die Wiederverwendung von Kennwörtern noch nicht recht, wie der Benutzer das ursprüngliche Passwort haben, wird darauf bestehen, weil er / sie will auch die anderen Seiten öffnen, aber Sie können versuchen, das rekonstruierte Passwort liefern in die sicherste Art und Weise (htpps und diskreter Auftritt auf der html).

Sorry, aber solange Sie eine Möglichkeit haben, ihr Passwort zu entschlüsseln, gibt es keine Möglichkeit, es sicher sein wird. Kampf es bitter, und wenn du verlierst, CYA.

kam gerade über diese interessante und hitzige Diskussion. Was mich am meisten überraschte war allerdings, wie wenig Aufmerksamkeit wurde auf die folgende grundlegende Frage bezahlt:

Q1. Was sind die tatsächlichen Gründe der Benutzer besteht darauf, den Zugriff auf Klartext gespeichert Passwort auf mit? Warum ist es so viel Wert?

Die Informationen, die Benutzer sind ältere oder junge antwortet nicht wirklich diese Frage. Aber wie eine unternehmerische Entscheidung kann ohne Verständnis Kunden Sorge gemacht werden?

Nun, warum es wichtig ist? Denn wenn die eigentliche Ursache der Anforderung der Kunden ist das System, das schmerzlich schwer zu bedienen ist, dann vielleicht die genaue Ursache Adressierung würde das eigentliche Problem lösen?

Als ich diese Informationen nicht haben und sprechen nicht auf die Kunden, kann ich nur raten:. Es geht um die Benutzerfreundlichkeit, siehe oben

Eine andere Frage, die ich gesehen habe gefragt:

Q2. Wenn der Benutzer das Passwort in erster Linie nicht erinnern, warum funktioniert die alte Passwort denn?

Und hier ist möglich Antwort. Wenn Sie Katze „miaumiau“ genannt und als Passwort ihren Namen, aber vergessen Sie haben, würden Sie erinnert werden es vorziehen, was es war, oder vielmehr ist so etwas wie „# zy * RW (ew“ geschickt habe?

Ein weiterer möglicher Grund ist, dass der Benutzer hält es für eine harte Arbeit mit einem neuen Passwort zu kommen! So hat geschickt das alte Passwort zurück gibt die Illusion wieder sie von dieser schmerzhaften Arbeit zu sparen.

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

Als Benutzer, möchte ich die Dinge einfach! Ich will nicht hart!

arbeiten

Wenn ich in eine Nachrichten-Website einzuloggen Zeitungen zu lesen, mag ich 1111 als Kennwort eingeben und seine durch !!!

Ich weiß, dass es unsicher ist, aber was gehe ich immer jemand Zugang zu meinem „Konto“? Ja, er kann auch die Nachricht lesen!

Ist die Website speichert meine „privaten“ Informationen? Die Nachricht las ich heute? Dann ist es das Problem der Website, nicht meine! Zeigt die Seite private Informationen zu authentifizierten Benutzer? Dann zeigen Sie es nicht in erster Linie!

Dies ist nur Benutzer-Einstellung für das Problem zu demonstrieren.

Um es zusammenzufassen, ich fühle mich nicht es ist ein Problem, wie „sicher“ speichern Passwörter im Klartext (was wir wissen, nicht möglich ist), sondern vielmehr, wie man Adress Kunden tatsächlich betreffen.

Handling verloren / vergessen Passwörter:

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

Wenn Benutzer ihre Passwörter vergessen, sie müssen zumindest ihren Benutzernamen oder E-Mail-Adressen kennen. Auf Wunsch eine GUID in der Tabelle Benutzer generieren und schickte eine E-Mail mit einem Link, die GUID als Parameter an den E-Mail-Adresse des Benutzers enthält.

Die Seite hinter dem Link überprüft, dass der Parameter guid wirklich existiert (wahrscheinlich mit einem gewissen Timeout-Logik), und fordert den Benutzer für ein neues Passwort ein.

Wenn Sie Hotline Hilfe Benutzer haben müssen, einige Rollen zu Ihrem Zuschüsse Modell hinzufügen und die Hotline Rolle erlauben als identifizierter Benutzer vorübergehend anmelden. Melden Sie alle diese Hotline-Anmeldungen. Zum Beispiel Bugzilla Angebote wie eine Identitätswechsel-Funktion admins.

Was ist das Klartext-Passwort bei der Anmeldung eine E-Mail, bevor sie verschlüsselt und verloren zu bekommen? Ich habe eine Menge von Websites gesehen tun, und von dem Benutzer des E-Mail das Passwort erhalten ist sicherer als es um auf dem Server / comp zu verlassen.

Wenn Sie nicht nur die Anforderung ablehnen erzielbare Passwörter zu speichern, wie etwa das als Gegenargument.

Wir können entweder richtig Hash-Passwörter und bauen für die Benutzer einen Reset-Mechanismus, oder wir können alle persönlichen Informationen aus dem System entfernen. Sie können eine E-Mail-Adresse einzurichten Benutzereinstellungen verwenden, aber das ist es. Verwenden Sie einen Cookie automatisch Einstellungen für zukünftige Besuche ziehen und die Daten weg nach einem angemessenen Zeitraum werfen.

Die einzige Option, die oft mit Kennwortrichtlinie zu übersehen ist, ob ein Passwort wirklich noch benötigt. Wenn das einzige, was Ihr tut Kennwortrichtlinie Ursache Anrufe beim Kundendienst ist, vielleicht können Sie es loswerden.

Haben die Benutzer wirklich Notwendigkeit zu erholen (z gesagt werden), was das Passwort vergessen hat, sie ist, oder brauchen sie einfach in der Lage sein, auf das System zu bekommen? Wenn das, was sie wirklich wollen ein Passwort-Anmeldung ist, warum nicht eine Routine haben, dass einfach das alte Passwort ändert (was immer es ist) in ein neues Kennwort, das der Support-Mitarbeiter auf die Person geben kann, dass sein Passwort vergessen?

Ich habe mit Systemen gearbeitet, die genau dies tun. Der Support-Mitarbeiter hat keine Möglichkeit zu wissen, was das aktuelle Passwort, aber es auf einen neuen Wert zurücksetzen. Natürlich sind alle solche Resets sollten Praxis angemeldet irgendwo und gut wäre, eine E-Mail an den Benutzer zu erzeugen, ihm zu sagen, dass das Passwort zurückgesetzt wurde.

Eine andere Möglichkeit ist gleichzeitig zwei Passwörter haben, auf ein Konto, die den Zugang. Eine davon ist die „normale“ Passwort, dass der Benutzer verwaltet und das andere ist wie ein Skelett / Master-Schlüssel, der nur vom Support-Mitarbeiter bekannt und ist das gleiche für alle Benutzer. Auf diese Weise, wenn ein Benutzer ein Problem hat die Unterstützung Person auf das Konto mit dem Master-Schlüssel anmelden kann und dem Benutzer sein Passwort ändern, um was auch immer helfen. Unnötig zu sagen, alle Anmeldungen mit dem Hauptschlüssel sollen auch vom System protokolliert werden. Als zusätzliche Maßnahme, wann immer der Hauptschlüssel verwendet wird Sie auch die Unterstützung Personen Anmeldeinformationen bestätigen könnten.

-EDIT- Als Reaktion auf die Kommentare über keinen Hauptschlüssel mit: Ich bin damit einverstanden, dass es schlecht ist, wie ich glaube, dass es schlecht ist, jemand anderes als der Benutzer zu ermöglichen, den Zugriff auf das Benutzerkonto zu haben. Wenn man sich die Frage sucht, ist die ganze Prämisse, dass der Kunde eine sehr kompromittiert Sicherheitsumgebung beauftragt.

Ein Hauptschlüssel muss nicht so schlimm, wie es zunächst scheint. Früher habe ich bei einer Verteidigungsanlage zu arbeiten, wo sie die Notwendigkeit für die Mainframe-Computer Betreiber wahrgenommen „spezielle Zugriff“ bei bestimmten Gelegenheiten zu haben. Sie setzen einfach das spezielle Passwort in einem versiegelten Umschlag und klebte es auf dem Schreibtisch des Bedieners. Um das Passwort zu verwenden (was der Betreiber wußte nicht) hatte er den Umschlag zu öffnen. Bei jedem Schichtwechsel eine der Aufgaben des Schichtleiters war zu sehen, ob der Umschlag geöffnet worden ist, und wenn ja, sofort das Passwort eines (durch eine andere Abteilung) geändert hat und das neue Passwort wurde in einem neuen Umschlag und der Prozess beginnt alles erneut. Der Bediener würde wie zu in Frage gestellt werden, warum er es geöffnet hatte, und der Vorfall würde für den Datensatz dokumentiert werden.

Dies ist zwar kein Verfahren ist, dass ich entwirft, hat es funktioniert und für eine ausgezeichnete Haftung zur Verfügung gestellt. Alles wurde protokolliert und überprüft, sowie alle Betreiber hatten DOD geheime Abstände und wir hatten nie irgendwelche Mißstände.

Aufgrund der Überprüfung und Überwachung, alle die Betreiber, dass wusste, wenn sie das Privileg, das Öffnen des Umschlags mißbraucht sie zur sofortigen Entlassung waren und mögliche Strafverfolgung.

Also habe ich die richtige Antwort erraten, wenn man will, Dinge tun richtige Mitarbeiter Menschen, die sie vertrauen können, tun Background Checks und ordnungsgemäße Verwaltung Aufsicht und Verantwortlichkeit auszuüben.

Aber dann wieder, wenn dieser arme Kerl des Kunden ein gutes Management hätte sie nicht für eine solche Sicherheit comprimised Lösung in erster Linie gefragt haben, jetzt sollten sie?

Von den kleinen, dass ich über dieses Thema zu verstehen, glaube ich, dass, wenn Sie eine Website mit einem signon / Passwort erstellen, dann sollten Sie nicht einmal das Klartext-Passwort auf dem Server überhaupt sehen. Das Passwort sollte gehasht, und wahrscheinlich gesalzen werden, bevor sie überhaupt den Client verlässt.

Wenn Sie noch nie das Klartext-Passwort sehen, dann ist die Frage des Abrufs nicht auf.

Auch ich sammle (aus dem Internet), die (angeblich) einige Algorithmen wie MD5 nicht mehr als sicher. Ich habe keine Möglichkeit, dass ich zu urteilen, aber es ist etwas zu prüfen.

Öffnen eine DB auf einem eigenständigen Server und gibt eine verschlüsselte Remote-Verbindung zu jedem Web-Server, der diese Funktion erfordert.
es muss nicht eine relationale DB sein, es kann ein Dateisystem mit FTP-Zugang sein, Ordner und Dateien anstelle von Tabellen und Zeilen.
gibt dem Web-Server schreibgeschützte Berechtigungen, wenn Sie können.

Speichern Sie die Nicht-abrufbaren Verschlüsselung des Passworts in der DB-Website (nennen wir es „Pass-a“) wie normale Menschen tun :)
auf jedem neuen Benutzer (oder das Passwort ändern) speichert eine einfache Kopie des Kennworts in der Remote-DB. verwenden Sie die ID des Servers, die Benutzer-ID und „Pass-a“ als Verbundschlüssel für dieses Passwort. Sie können sogar eine bidirektionale Verschlüsselung auf dem Passwort, um zu schlafen verwenden besser in der Nacht.

jetzt, um für jemanden, sowohl um das Passwort zu bekommen, und es Kontext (Site-ID + Benutzer-ID + "Pass-a"), muss er:

Hack der DB Webseite ein ( "Pass-a", Benutzer-ID) oder die Paare zu erhalten.
erhalten Sie die ID der Website von einer Config-Datei
finden und hacken in die Remote-Passwörter DB.

Sie die Erreichbarkeit des Passworts Retrieval Service steuern kann (setzen Sie es nur als ein gesichertes Web-Service, nur bestimmte Menge an Passwörtern Auslagerungen pro Tag, tun Sie es manuell, etc.), und sogar extra für diese „besondere Sicherheits aufladen Anordnung“.
Die Passwörter Retrieval DB-Server ist ziemlich versteckt, da es nicht viele Funktionen dient nicht und besser gesichert werden kann (man kann Schneider Berechtigungen, Prozesse und Dienstleistungen fest).

Alles in allem machen Sie die Arbeit schwieriger für den Hacker. die Möglichkeit einer Sicherheitsverletzung auf einem einzelnen Server ist immer noch die gleiche, aber aussagekräftige Daten (eine Übereinstimmung von Konto und Passwort) werden zusammen hart sein.

Eine weitere Option, die Sie möglicherweise nicht in Betracht gezogen haben, ist erlaubt Aktionen per E-Mail. Es ist ein bisschen umständlich, aber ich implementiert dies für einen Kunden, dass benötigte Benutzer „außerhalb“ ihr System Ansicht (nur lesen) bestimmte Teile des Systems. Zum Beispiel:

Sobald ein Benutzer registriert ist, sie haben vollen Zugriff (wie bei einem normalen Webseite). Die Anmeldung muss eine E-Mail enthalten.
Wenn Daten oder eine Aktion benötigt wird, und der Benutzer nicht erinnern sich an ihr Passwort können sie führen immer noch die Wirkung von Klicke auf einem speziellen " E-Mail mich für die Erlaubnis, " Taste, direkt neben dem regulären " Senden " Taste.
Die Anforderung wird dann mit einem Hyperlink zu fragen an die E-Mail verschickt, wenn sie die Aktion durchgeführt werden soll. Dies ist vergleichbar mit einem Passwort-Reset-E-Mail-Link, sondern das Passwort zurückzusetzen, führt sie die einmalige Aktion .
Der Benutzer klickt dann auf „Ja“, und es wird bestätigt, dass die Daten angezeigt werden sollen, oder die Aktion ausgeführt werden soll, Daten zeigten, etc.

Wie Sie in den Kommentaren erwähnt, wird dies nicht funktionieren, wenn die E-Mail-gefährdet ist, aber es hat Adresse @joachim ‚s Kommentar über nicht wollen, das Passwort zurücksetzen können. Schließlich würden sie das Passwort-Reset verwenden müssen, aber sie können, dass bei einem günstigeren Zeitpunkt tun, oder mit Hilfe eines Administrators oder Freund, je nach Bedarf.

Eine Torsion zu dieser Lösung wäre es, die Aktions-Anforderung an einen Dritten vertrauenswürdigen Administrator zu senden. Dies würde funktioniert am besten in Fällen mit den älteren, geistig behinderten, sehr jung oder sonst verwirrten Benutzer. Natürlich erfordert dies eine vertrauenswürdige Administrator für diese Menschen ihre Aktionen zu unterstützen.

Salz-und-Hash das Kennwort des Benutzers als normal. Wenn in den Benutzer anmelden, damit sowohl das Kennwort des Benutzers (nach dem Salzen / Hashing), sondern auch ermöglichen, was der Benutzer buchstäblich passen eingegeben.

Dies ermöglicht der Benutzer ihr geheimes Passwort einzugeben, sondern auch ermöglicht es ihnen, die gesalzen / gehashten Version ihres Passwort einzugeben, das, was jemand aus der Datenbank gelesen würde.

Im Grunde macht das gesalzene / gehashten Passwort sein auch ein „Klartext“ Passwort.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow