Frage:
Was ist eine gute Analogie, um einem Laien zu erklären, warum Passwörter gehasht werden sollten?
Nzall
2014-07-18 16:29:51 UTC
view on stackexchange narkive permalink

Hinweis: Dies ist keine aktuelle Situation, in der ich mich gerade befinde.

Angenommen, Ihr Chef ist einer dieser altmodischen Manager für Computer-Analphabeten und möchte die Passwörter im Klartext speichern, um die Entwicklung zu vereinfachen. Sie haben 5 Minuten Zeit, um den Punkt des Hashens von Passwörtern zu erklären. Sie wissen auch aus Erfahrung, dass Ihr Chef durch eine gute Analogie beeinflusst werden kann. Welche Analogie würden Sie verwenden, um Ihrem Chef zu erklären, dass Passwörter gehasht werden sollten?

Wenn technische Gespräche auf Defekte stoßen, kann es an der Zeit sein, über die Haftung zu sprechen.
@DavidHoude Ich stimme dem zu, aber Ihr Chef könnte sagen "Lassen Sie uns das besprechen, wenn es soweit ist". Zu diesem Zeitpunkt ist es zu spät. Haftung ist ein guter Grund für sich, aber nicht jeder kümmert sich gleichermaßen darum. Angenommen, Sie müssen es einem Praktikanten erklären, der sich nicht wirklich um die Haftung kümmert, weil er wahrscheinlich nicht mehr mit Ihnen zusammenarbeitet, sobald der Hack passiert.
@Nate: Diesen Vorgesetzten erklären Sie, dass ** sie ** sich wohl fühlen, wenn sie die Haftung übernehmen, aber dass ** Sie ** dies nicht tun. Wenn sie also bitte einen Verzicht unterzeichnen könnten, der im Namen des Unternehmens alle Haftung für die Haftung übernimmt technische Entscheidung (dh kein Hashing), die sie getroffen und von Ihnen ausgeführt haben. Das zieht den Moment nach vorne, in dem sie nachdenken müssen.
Hier ist eine Analogie: Es gab einmal einen König, der nicht hören wollte, was in seinem Königreich vor sich ging. Er war eine sehr wichtige Person, die keine Zeit hatte, sich Gedanken zu machen. Aber weil er verantwortlich war, musste er viele Entscheidungen treffen. Er wäre kein großer König, wenn er seine Berater tun lassen würde, was sie für am besten hielten! Also befahl er seinen Beratern, ihm erfundene Geschichten zu erzählen und ihn dann zu fragen, was er in der Geschichte tun würde. Natürlich wurde sein Königreich besetzt, er wurde getötet und seine Burg dem Erdboden gleichgemacht. Aber zumindest musste er nicht darüber nachdenken und er genoss die Geschichten.
Die Analogie, die ich verwenden würde, ist der Safe. Der Safe verfügt über zwei Schlösser mit separaten Schlüsseln. Die Bank hat einen Schlüssel (nennen wir ihn den Benutzer-ID-Schlüssel) und Sie haben den anderen (nennen wir ihn den Passwortschlüssel). Was würden Sie denken, wenn Sie herausfinden würden, dass die Bank eine Kopie des Passwortschlüssels heimlich aufbewahrt?
Keine Notwendigkeit für eine Analogie, drehen Sie einfach den Spieß um und bitten Sie ihn, Ihnen einen guten Grund zu nennen, warum Sie keine Hash-Passwörter verwenden sollten.
"Wenn Sie mich nicht zum ersten Mal verärgern, werde ich Ihr Passwort verwenden, um mich als Sie anzumelden und einen Teil des Unternehmensvermögens auf Ihren Namen zu übertragen."
pfft. Anscheinend darf ich keine Antwort mit 101 Ruf veröffentlichen ... hier ist eine andere Analogie, die ich viel passender finde als jedes Beispiel eines Schließfachs usw. Stellen Sie sich vor, Sie möchten in eine sehr exklusive Bar für Hellseher gehen. Der Türsteher hält eine Karte hoch, damit nur er sie sehen kann, und fragt Sie, welches Bild darauf abgebildet ist. Wenn Sie richtig antworten können - so die Annahme - sind Sie psychisch und können somit eintreten. Dies ist das Klartextkennwort. Solange alles nach Plan läuft, ist das in Ordnung.
Aber stellen Sie sich jetzt vor, Sie hätten die Bartür vom falschen Verkäufer gekauft und es gibt kleine Spiegel, die sie bedecken, oder der Türsteher hat beschlossen, eines Tages verspiegelte Sonnenbrillen zu tragen. Plötzlich sind diese Bilder, die von außen niemals gesehen werden sollten, für jeden sichtbar, der sich genug anstrengt. Das Hashing des Passworts ist wie das Einstecken der Karte in einen Umschlag. Selbst wenn Sie von innen schauen (direkt oder über falsch installierte Spiegel), kann das Bild erst erraten werden, wenn ein Passwort benannt wurde und der Türsteher den Umschlag öffnet, um ihn zu überprüfen. (Dieses letzte Bit ist technisch falsch, sollte aber den Punkt überkreuzen).
Weil * Sie * der Entwickler sind und es Ihre Aufgabe ist, sichere Software zu entwickeln - Ihr Chef hat Sie eingestellt, weil Sie Computer kennen und er nicht - und Sie haben eine ethische und professionelle Verpflichtung dazu.
Anscheinend ist das Netzwerk mit 101 Wiederholungen nicht gut genug, also los geht's ... Okay, nehmen wir an, Ihr Kunde gibt Ihnen eine Tüte Kuchenmischung mit einem präzisen Satz Zutaten. Sie backen den Kuchen und probieren ihn. Jetzt, da Sie eine erstaunliche Zunge haben, können Sie den Unterschied zwischen den Kuchen von zwei beliebigen Kuchenmischungen erkennen. Das Speichern der Kuchenmischung ist wie das Speichern eines Passworts. Wenn es gestohlen wird, können sie es wiederverwenden. Wenn Sie den Kuchen backen und aufbewahren, können sie die genaue Zusammensetzung der Zutaten nicht herausfinden, selbst wenn sie den Kuchen stehlen. Die Kuchenmischung ist wie ein Passwort und der Kuchen ist der Hash.
Unhashed Passwörter sind so, als würden Sie einen Stapel von 20 auf Ihrem Autositz lassen. Sicher, dein Auto ist verschlossen ...
Warum hasst du sie nicht einfach? Ich meine, ich weiß, es wird dich wahrscheinlich entlassen - aber ... Willst du wirklich als der Techniker bekannt sein, der für diese Firma gearbeitet hat, die ihre Passwörter nicht gesichert hat?
@SteveJessop Das ist keine Analogie. So haben buchstäblich einige Manager die Welt gesehen. Machen wir es nicht noch schlimmer, indem wir sie daran erinnern, dass sie Könige sind?
@corsiKa: gut, vielleicht könnte die Antwort auf meine "Analogie" verwendet werden, um zwischen Managern zu unterscheiden, die zulassen, dass "nicht wissen wollen, was los ist und keine Zeit zum Nachdenken haben, aber nicht delegieren" Ich mache keine großartige Arbeit gegen Manager, gegen die wir unsere kaum verhüllte Drohung, ihr Schloss zu zerstören, gut machen sollten.
[Der letzte Absatz in diesem Artikel ist ziemlich nett.] (Http://blog.codinghorror.com/rainbow-hash-cracking/) Denken Sie daran, mit `Salting a Hash zu beginnen, klingt kompliziert (und vage lecker), aber es ist ganz einfach. "
Ein Hash funktioniert wie ein Passwort für Ihr Passwort. Wenn jemand das Passwort für Ihre nicht gehashte Datenbank erhält, hat er Zugriff auf alle Passwörter Ihrer Benutzer. Wenn jedoch für jedes Passwort ein Passwort erforderlich ist, muss jedes Passwort verwendet werden auch einzeln geknackt, was ein nicht triviales Problem ist.
Hashing ist wie ein perfekt konsistenter Dichter, der für jedes Passwort ein Gedicht schreibt.Sie können das Passwort nicht aus dem Gedicht ableiten, aber der Dichter wird immer das gleiche Gedicht für ein bestimmtes Passwort verfassen.Die Gedichte sind nur dann wertvoll, wenn Sie Zugriff auf den Dichter haben. Es schadet also nicht, die Gedichte in der Datenbank zu speichern, falls sie gestohlen werden.
Achtzehn antworten:
#1
+233
tylerl
2014-07-18 21:56:01 UTC
view on stackexchange narkive permalink

Die kurze Antwort

Die kurze Antwort lautet: "Sie werden also nicht von einer Sammelklage in Höhe von 5 Millionen US-Dollar betroffen." Das sollte für die meisten CEOs Grund genug sein. Das Hashing von Passwörtern ist viel billiger.

Aber was noch wichtiger ist: Das einfache Hashing der Passwörter, wie Sie es in Ihrer Frage vorgeschlagen haben, reicht nicht aus. Sie werden immer noch die Klage bekommen. Sie müssen mehr tun.

Warum Sie mehr tun müssen, dauert etwas länger, um es zu erklären. Nehmen wir also einen Moment den langen Weg, damit Sie verstehen, was Sie erklären, und dann kreisen wir um Ihre 5-minütige Zusammenfassung.

Hashing ist nur der Anfang

Aber fangen wir damit an. Angenommen, Sie speichern die Passwörter Ihrer Benutzer wie folgt:

  # id: Benutzer: Passwort1: Alice: Pizza2: Bob: Passw0rd3: Carol: Baseball  

Jetzt Angenommen, ein Angreifer erhält mehr Zugriff auf Ihr System, als Sie möchten. Er ist nur 35 Sekunden lang da, bevor Sie das Problem erkennen und das Loch schließen. Aber in diesen 35 Sekunden hat er es geschafft, Ihre Passwortdatenbank zu knacken. Ja, Sie haben einen Sicherheitsfehler gemacht, aber Sie haben ihn jetzt behoben. Sie haben das Loch gepatcht, den Code repariert und Ihre Firewall aktualisiert, was auch immer es sein mag. Jetzt ist also alles gut, oder?

Nun, nein, er hat Ihre Passwortdatenbank.

Das bedeutet, dass er sich jetzt als jeder Benutzer auf Ihrem System ausgeben kann. Die Sicherheit Ihres Systems wird zerstört. Die einzige Möglichkeit zur Wiederherstellung besteht darin, mit der NEUEN Kennwortdatenbank neu zu beginnen und alle zu zwingen, ihr Kennwort zu ändern, ohne ihr vorhandenes Kennwort als gültige Form der Identifizierung zu verwenden. Sie müssen sie über eine andere Methode (Telefon, E-Mail oder ähnliches) außerhalb des Bandes kontaktieren, um ihre Identität zu überprüfen und ihre Passwörter neu zu erstellen. In der Zwischenzeit ist Ihr gesamter Vorgang tot im Wasser.

Und wenn Sie nicht gesehen haben, dass er die Passwortdatenbank gestohlen hat? Rückblickend ist es ziemlich unwahrscheinlich, dass Sie es tatsächlich sehen würden. Die Art und Weise, wie Sie dies wahrscheinlich herausfinden, besteht darin, ungewöhnliche Aktivitäten auf den Konten mehrerer Benutzer zu bemerken. Vielleicht ist es monatelang so, als ob Ihr System überhaupt keine Sicherheit hat und Sie nicht herausfinden können, warum. Dies könnte Ihr Unternehmen ruinieren.

Also haben wir Hash

Anstatt das Passwort zu speichern, speichern wir einen Hash des Passworts. Ihre Datenbank sieht jetzt folgendermaßen aus:

  # id: user: sha11: alice: 1f6ccd2be75f1cc94a22a773eea8f8aeb5c682172: bob: 7c6a61c68ef8b9b6b061b28c348bc1ed7921cb533d22c Ihr Speicher ist ein undurchsichtiges Token, mit dem  überprüft werden kann,  ob ein Kennwort korrekt ist, aber nicht verwendet werden kann, um  das richtige Kennwort abzurufen.  

Na ja, fast. Google diese Hashes, ich wage dich.

Jetzt sind wir also zur Technologie der 1970er Jahre übergegangen. Herzliche Glückwünsche. Wir können es besser machen.

Also salzen wir

Ich habe lange Zeit die Frage beantwortet, warum Hashes gesalzen werden sollen, einschließlich Beispielen und Demonstrationen, wie dies in der realen Welt funktioniert. Ich werde die Hashing-Diskussion hier nicht erneut hashen, also lesen Sie das Original:

Warum sind gesalzene Hashes sicherer?

Ziemlich viel Spaß , wie? OK, jetzt wissen wir, dass wir unsere Hashes salzen müssen, oder wir hätten die Passwörter genauso gut nie von Anfang an hashen können. Jetzt sind wir auf dem neuesten Stand der Technik der 90er Jahre. Wir können es immer noch besser machen.

Also iterieren wir

Sie haben dieses Bit am Ende der Antwort bemerkt, die ich oben verlinkt habe, richtig? Das bisschen über bcrypt und PBKDF2? Ja, es stellt sich heraus, dass das wirklich wichtig ist. Mit der Geschwindigkeit, mit der Hardware heute Hashing-Berechnungen durchführen kann ( danke, Bitcoin!), kann ein Angreifer mit handelsüblicher Hardware innerhalb weniger Stunden Ihre gesamte gesalzene, gehashte Kennwortdatei durchblasen Berechnen von Milliarden oder sogar Billionen von Hashes pro Sekunde. Sie müssen sie verlangsamen.

Der einfachste Weg, sie zu verlangsamen, besteht darin, sie dazu zu bringen, mehr Arbeit zu erledigen. Anstatt einen Hash zu berechnen, um ein Passwort zu überprüfen, müssen Sie 1000 oder 100.000 berechnen. Oder welche Zahl auch immer zu Ihnen passt. Sie können auch scrypt ("ess-crypt") verwenden, was nicht nur viel CPU-Leistung, sondern auch viel RAM für die Berechnung erfordert, wodurch die oben verlinkte dedizierte Hardware weitgehend unbrauchbar wird

Dies ist der aktuelle Stand der Technik. Herzlichen Glückwunsch und willkommen zur heutigen Technologie.

Sind wir fertig?

Was passiert nun, wenn der Angreifer Ihre Kennwortdatei abruft? Nun, jetzt kann er offline darauf loslegen, anstatt online Vermutungsversuche gegen Ihren Dienst zu unternehmen. Leider hat ein angemessener Teil Ihrer Benutzer (4% bis 12%) das Kennwort "123456" oder "Kennwort" verwendet, es sei denn, Sie verhindern dies aktiv, und der Angreifer wird versuchen, diese zuerst zu erraten.

Wenn Sie die Sicherheit von Benutzern gewährleisten möchten, lassen Sie sie nicht "Passwort" als Passwort verwenden. Oder eine der anderen Top 500. Es gibt Software, mit der die genaue Berechnung der Kennwortstärke einfach (und kostenlos) durchgeführt werden kann.

Aber auch die Multi-Faktor-Authentifizierung ist niemals ein schlechter Anruf. Es ist einfach für Sie, jedem Projekt etwas hinzuzufügen. Das können Sie auch.

Nun, Ihre 5 Minuten des Ruhms

Sie stehen vor Ihrem Chef und er fragt Sie, warum Sie PBKDF2 oder ähnliches verwenden müssen um Ihre Passwörter zu hashen. Sie erwähnen die Sammelklage von LinkedIn und sagen: "Dies ist das in der Branche gesetzlich erwartete Mindestmaß an Sicherheit. Alles andere ist buchstäblich Nachlässigkeit." Dies sollte weniger als 5 Minuten dauern, und wenn Ihr Chef nicht überzeugt ist, hat er nicht zugehört.

Aber Sie könnten fortfahren: "Die Kosten für die Implementierung der Hashing-Technologie sind vernachlässigbar, während die Kosten für die nicht -Implementierung in Millionenhöhe oder höher liegen könnten." und "Im Falle eines Verstoßes können Sie sich mit einer ordnungsgemäß gehashten Datenbank als gut geführte sicherheitsbewusste Organisation positionieren, während eine nicht ordnungsgemäß gehashte Datenbank eine sehr öffentliche Verlegenheit darstellt, die, wie die Geschichte vielfach gezeigt hat, dies auch tun wird." nicht von den Medien ignoriert oder im geringsten übersehen werden. "

Wenn Sie technische Informationen benötigen, können Sie die oben genannten Punkte erneut überprüfen. Aber wenn Sie mit Ihrem Chef sprechen, sollten Sie es besser wissen. Und Analogien sind viel weniger effektiv, als nur die realen Effekte zu zeigen, die perfekt sichtbar sind, ohne dass eine Zuckerbeschichtung erforderlich ist.

Sie bringen Menschen nicht dazu, Schutzhandschuhe zu tragen, wenn Sie eine gute Analogie erzählen . Stattdessen geben Sie etwas Mittagsfleisch in das Becherglas und wenn es in grünen und blauen Flammen explodiert, sagen Sie: "Das passiert mit Ihrem Finger."

Verwenden Sie hier das gleiche Prinzip.

Es ist hier die Herausforderung, es in fünf Minuten zu erklären (oder eine Analogie zu finden, die funktioniert, je nachdem, ob Sie sich mehr auf den Titel oder den Inhalt der Frage konzentrieren), und ich glaube nicht, dass diese Antwort funktionieren würde. Nur * dies * zu lesen und Ihre verknüpfte Antwort allein wird wahrscheinlich die meisten Leute fünf Minuten brauchen.
+1 ohne Analogie, es gibt Beispiele aus dem wirklichen Leben, und sie sind viel sinnvoller als "eine riesige Hürde".
Ein Kommentar: Ich habe diese Linkedin-Klage nachgeschlagen und sie wurde abgewiesen (obwohl der Grund für die Abweisung nicht darin bestand, dass die Passwörter schlecht gehasht wurden). Ich werde es jedoch meinen Mitarbeitern zeigen, da es mögliche Konsequenzen für die Verwendung von SHA-1 zeigt. Ich habe auch eine Website mit 15 Milliarden SHA-1-Hashes gefunden, die ich als weiteren Beweis verwenden werde.
„Man bringt die Leute nicht dazu, Schutzhandschuhe zu tragen, wenn man eine gute Analogie erzählt. Stattdessen gibst du etwas Mittagsfleisch in das Becherglas und wenn es in grünen und blauen Flammen explodiert, sagst du: "Das wird mit deinem Finger passieren." „Etwas vage Fingerartiges zu verwenden, um zu demonstrieren, was mit dem tatsächlichen Finger eines Menschen geschehen wird, ist * buchstäblich * eine Analogie.
Nach meinem Verständnis werden Verschlüsselung oder Verschlüsselung gegenüber PBKDF2 bevorzugt, da sie wesentlich widerstandsfähiger gegen Hardwarebeschleunigung sind.
2FA / MFA kann * manchmal * "ein schlechter Anruf" sein. Wenn Sie jeden Benutzer zwingen, es unter Umständen mit geringer Sicherheit ständig zu verwenden, können Sie sehr schnell * Sicherheitsmüdigkeit * verursachen. Ich möchte nicht jedes Mal, wenn ich mich bei Facebook anmelde, einen Iris-Scan und eine Stuhlprobe einreichen müssen. Wenn Ihre Daten nicht * so * riskant sind, ** machen Sie 2FA / MFA optional **. Sie werden sicherheitsparanoide Benutzer glücklich machen, ohne die Faulheit zu erschöpfen, und Sie können die Haftung auf die Personen übertragen, die sich abmelden.
Der * einzige * Teil dieser Antwort, der zählt, ist der allererste Satz: Aus Sicht eines Managers dreht sich alles um Haftung. Wenn sie das nicht verstehen, sind sie nicht in der Lage zu verwalten.
In dem Link zu der Klage, die Sie erwähnt haben, ist mir Folgendes aufgefallen: "Es ist üblicher, die Passwörter vor der Eingabe in eine Hash-Funktion zu salzen, dann den resultierenden Hash-Wert zu salzen und den Hash-Wert erneut durch eine Hash-Funktion auszuführen." Ich verstehe, dass das wiederholte Hashing dazu führen muss, dass das Hashing von Passwörtern lange dauert. Und der Sinn eines Salzes besteht darin, sicherzustellen, dass jedes Passwort einzeln gehasht werden muss (anstatt über die gesamte Datenbank zu raten, zu hashen und zu vergleichen). Aber ich sehe keinen Vorteil darin, mehrmals zu salzen. Vermisse ich etwas
Ich folgte dir bis "Also iterieren wir." Ich habe keine Ahnung, wie man das implementiert, was auch immer das bedeutet, so dass ich nicht die 90er-Technologie verwende, um nur gehashte Passwörter zu salzen. :) :)
@NateKerkhofs könnten Sie auf diese Seite hinweisen?
@HC_-Funktionen zur iterativen Schlüsselableitung wie pbkdf2 und scrypt führen dazu, dass der Hashing-Schritt länger dauert. Die Idee ist, dass ein Angreifer nicht so viele Versuche unternehmen kann, wenn es länger dauert. Es gibt viel mehr Informationen zu diesem Thema, Google wird Sie dazu führen.
Ich habe den ersten Hash gegoogelt. Das erste Ergebnis war "Wie sagt man 1f6ccd2be75f1cc94a22a773eea8f8aeb5c68217 auf Deutsch?"
@woliveirajr https: // crackstation.net / verfügt über eine 190-GB-Datenbank mit 15 Milliarden Passwörtern und Hashes für MD5 und SHA-1. Sie haben auch eine 19-GB-Datenbank mit 1,5 Milliarden Hashes für eine Reihe anderer Hashing-Algorithmen. Ich habe sie für die Beispiel-Hashes getestet und sie funktioniert.
"Re-Hash das oben" sehen, was du getan hast :)
Nun, aber hmm. Dies beantwortet die Frage nicht wirklich. Die Frage war nicht: "Wie kann ich einen Laien davon überzeugen, dass dies eine gute Sache ist?" aber "Wie kann ich dies einem Laien so erklären, dass er das technische Konzept versteht?" Die bloße Behauptung, dass ein Richter mir zustimmt, dass dies eine gute Idee ist, erklärt nicht, WARUM es eine gute Idee ist. Und andere Dinge zu erklären, die man auch tun könnte, um es noch besser zu machen, erklärt nicht, warum der erste Schritt von Anfang an eine gute Idee war. Nicht dass die Antwort keine wertvollen Informationen enthält. Es ist nur die Antwort auf eine andere Frage.
Diese Antwort ist in Bezug auf Fakten zu 100% richtig, aber keine Antwort auf die gestellte Frage. Die Frage war nicht * "warum ist Hashing nützlich" * oder * "was sind die heutigen Sicherheitserwartungen in der Branche" *. Die Frage war * "Welche ** Analogie ** kann verwendet werden, um Hashing zu beschreiben" * und diese Antwort scheint nicht in Beziehung zu stehen (und überflüssig, wenn man bedenkt, dass es wahrscheinlich Dutzende von Antworten auf dieser Site gibt, warum Hash + Salting verwendet wird). Ich denke, wenn Sie mit der Prämisse der Frage nicht einverstanden sind, sollten Sie einen Kommentar hinterlassen und darum bitten, dass er umformuliert wird, und keine andere Frage beantworten.
Ich denke, diese Antwort deutet auf rechtliche Auswirkungen hin und das ist nicht wirklich angemessen. Ein Unternehmen muss wahrscheinlich nur nachweisen, dass es "branchenübliche Praktiken" befolgt, um abgedeckt zu werden, und selbst grundlegendes Hashing könnte dazu passen. Aber Sie würden es nicht sicher herausfinden, bis Sie in einem Gerichtssaal sind, und verschiedene Gerichte könnten es unterschiedlich finden und es würde wahrscheinlich von Expertenaussagen usw. usw. abhängen.
#2
+45
aaaaaaaaaaaa
2014-07-19 12:56:25 UTC
view on stackexchange narkive permalink

Dieser Thread enthält einige Analogien.

Ein nicht verwaschenes Passwort ist wie ein transparentes Schloss. Jeder, der es sich genau ansieht, kann den passenden Schlüssel entwerfen.

Ich würde mit ungeschliffenen = Vergleichsschlüsseln und ungesalzenen = transparenten Schlössern gehen
@Bergi Ich kann daraus keinen bissigen Satz machen, und angesichts der Art und Weise, wie Sie den Vorschlag liefern, können Sie das wohl auch nicht.
Vielleicht nicht so bissig wie deins, aber ich werde es versuchen: Ein nicht verwaschenes Passwort ist wie ein Ersatzschlüssel, der mit dem des Benutzers verglichen wird. Jeder, der Zugang zum Schlüsselraum erhält, kann jedoch Kopien davon anfertigen. Wir speichern also keine Schlüssel, sondern Sperren, die vom jeweiligen Schlüssel des Benutzers geöffnet werden müssen. Mit dem Zugang zum Umkleideraum könnte man die Schlösser öffnen, und da sie alle transparent sind und vom selben Hersteller stammen, ist es ziemlich einfach, einen Pick zu finden, der einige öffnet. Also salzen wir unsere Hashes, was wie die Verwendung vieler verschiedener Schlossmodelle ist, sodass sie einzeln ausgewählt werden müssen.
Leider [kann ich es nicht als Antwort posten] (http://meta.stackexchange.com/q/170937/183280), auch wenn es die Länge der Kommentarlänge fast überschritten hat :-)
@Bergi Punkte für den Versuch, aber diese Erklärung ist fast so kompliziert wie die einfache Erklärung von Passwort-Hashes. Der Sinn der Analogie besteht nicht darin, die eigentliche Erklärung zu ersetzen, sondern eher darin, ein Rettungsboot für diejenigen zu finden, die die wirkliche Erklärung nicht verstehen. Zu diesem Zweck ist es äußerst wichtig, einfach und einprägsam zu sein.
Ja, das stimmt, und "transparentes Schloss" ist ein prägnanter Satz, den sich jeder vorstellen kann (Sie haben sowieso meine Gegenstimme). Ich denke jedoch, dass eine Analogie keine Erklärung ersetzen muss, sondern sollte / könnte dazu beitragen und helfen, sie in nicht / weniger technischen Begriffen zu verstehen, indem sie denselben Gedankengang durchläuft. Die Verwendung intransparenter Sperren klingt zu sehr nach Sicherheit durch Dunkelheit :-)
Nein, ein nicht verwaschenes Passwort ist wie ein Schlüssel? Sie können es verwenden, um ihr Konto zu entsperren? Und wenn das der Fall ist - oder wenn Ihre Antwort der Fall ist - was zum Teufel ist dann ein * gehashtes * Passwort? Das ist viel mehr wie ein Schloss, in das Sie Brute-Key-Brute-Brute-Brute-Force-Schlüssel einbauen können.
#3
+29
Nzall
2014-07-18 16:29:51 UTC
view on stackexchange narkive permalink

Zunächst stelle ich Folgendes zur Verfügung:

Stellen Sie sich vor, Sie verwalten eine Bank. Sie möchten Ihren Kunden keinen direkten Zugriff auf das Geld gewähren. Sie haben also einen Kassierer, der nur über einen Computer und einen kleinen Geldbetrag verfügt, um die täglichen Abhebungen und Einzahlungen zu erledigen. Er kann weder auf alles zugreifen noch Geheimnisse an den Kunden weitergeben, weil er keinen Zugriff auf diese Geheimnisse hat.

Ein Kassierer ist in Ordnung und gut, aber manchmal haben Sie eine Person, die dies möchte beraubt die Bank und er wird nicht wirklich vom Kassierer aufgehalten. Um dem entgegenzuwirken, haben Sie einen wirklich großen Safe in Ihrem Keller, der das gesamte echte Geld Ihrer Kunden enthält. Dieser Safe verfügt über eine Reihe von Sicherheitsvorkehrungen wie einen Fingerabdruckscanner, Spracherkennung, Druckschalter, Dreifachschlösser und ein Zeitschloss. Es wurde entwickelt, um alle fernzuhalten, die nicht da sein sollten und nicht wissen, wie sie an der Sicherheit vorbeikommen sollen.

Dieser Safe wird 99% der Räuber aufhalten, aber es gibt immer diese 1% schafft es, all diese Sicherheit zu überwinden, indem man sie entweder umgeht oder brutalisiert. In diesem Fall lagert eine Bank ihr Geld in Sprengfallenbehältern, die das Geld unbrauchbar machen, beispielsweise durch Sprengen oder Sprühen von Farbe. Auf diese Weise kann der Räuber das Geld entweder nicht verwenden oder muss viel Zeit aufwenden, um das Geld wieder nutzbar zu machen.

Eine Softwareanwendung verfügt auch über diese Systeme: Das Programm, das der Benutzer verwendet, ist der Kassierer: Er kann es nicht dazu bringen, das zu tun, was er will, es sei denn, er findet einen Weg, es in eine Zusammenarbeit zu bringen. Die Hardware- und Softwarekonfiguration, die das Programm und die Datenbank schützt, ist der Banktresor: Sie hält die Personen fern, die die Schwachstellen der verwendeten Sicherheitskonfiguration nicht kennen. Das Speichern des Passworts im Klartext bedeutet, dass jemand, der das Programm und die Sicherheitskonfiguration hinter sich lässt, freien Zugriff auf die Passwörter hat. So wie eine Bank das Geld in einem Container aufbewahrt, der den Zugriff auf das Geld erheblich erschwert, bietet das Hashing des Passworts der Person, die Ihre Passwörter kompromittiert, eine riesige Hürde, die sie überwinden muss. Dies bedeutet auch, dass die Mitarbeiter (sowohl die Bank, die Software als auch die unseres eigenen Unternehmens) nicht unter Druck gesetzt, gezwungen oder überredet werden können, die Sicherheit für einen Betrüger zu umgehen, da nicht einmal sie direkt auf das Geld / die Passwörter zugreifen können. Sie können nur auf die Container / den Hash zugreifen.

Du hast mich verloren, weil ich das Passwort gehasht habe (das ist eine riesige Hürde) (weshalb ich normalerweise keine Analogien mag).
@njzk2 "X ist eine Hürde" ist eine so verbreitete Phrase, dass es kaum eine Analogie ist. Es ist nur eine idiomatische Art zu sagen: "X macht die Aufgabe schwierig."
#4
+14
GdD
2014-07-18 17:49:36 UTC
view on stackexchange narkive permalink

Ich mag Analogie als Erklärung für Technologie, aber in diesem Fall ist sie wahrscheinlich nicht praktikabel, da die Analogie zu komplex wäre.

Die meisten Manager sind motivierter, persönliche Risiken für ihre Position zu vermeiden, als das Richtige zu tun. Daher würde ich anstelle einer Analogie Beispiele verwenden, bei denen sich das Speichern von Passwörtern im Klartext schlecht auf ein Unternehmen ausgewirkt hat. Ich würde nur so etwas wie

sagen. "Das Speichern von Passwörtern im Klartext würde dazu führen, dass wir sehr schlecht aussehen, unseren Ruf gefährden und uns möglicherweise für Rechtsstreitigkeiten öffnen. Dies wird in jeder Branche und dort als sehr schlechte Praxis angesehen Es handelt sich um Websites, auf denen Unternehmen benannt und beschämt werden, die Passwörter im Klartext speichern. Persönlich möchte ich nicht derjenige sein, der vor dem Vorstand / Chef / CTO steht und erklärt, warum wir keine grundlegende Sicherheitskontrolle eingerichtet haben. Wenn wir die Passwörter unserer Kunden hashen, würde ein Datenverstoß nicht zu einem sofortigen Verlust von Passwörtern führen, die Hacker verwenden könnten, und wir würden die Informationen unserer Kunden schützen. Das Hashing von Passwörtern verringert ein großes Risiko für geringen Aufwand. "

Fügen Sie Links zu Plain Text Offenders hinzu und senden Sie dann Likes an einige Nachrichten wie Cupid Media, Microsoft India Store usw. .

+1 für Plain Text Offenders - Es scheint ziemlich einfach zu sein, Ihrem Chef zu zeigen, dass das Unternehmen in der Öffentlichkeit von einer Website lächerlich gemacht wird, die hervorragend erklärt und verteidigt, warum sie das tun. Zumal es so einfach ist, bewährte Verfahren umzusetzen
#5
+13
brokethebuildagain
2014-07-18 22:21:18 UTC
view on stackexchange narkive permalink

Analogien zu verwenden kann mächtig sein, aber in diesem Fall wäre es meiner Meinung nach viel einfacher, nur in einfacher Sprache zu erklären, was los ist. So etwas sollte effektiv sein, sollte aber wahrscheinlich Powerpoint-Folien mit Abbildungen und großen Unternehmensschriftarten enthalten.

Wie Sie wissen, müssen Benutzer Kennwörter verwenden, damit wir wissen, wer sie sind, wenn sie sind mit unserem Produkt. Wir müssen diese Passwörter im Auge behalten, damit sich Benutzer anmelden können. Das Problem ist, dass wir die Passwörter nicht genau so speichern können, wie sie eingegeben wurden, da Angreifer Möglichkeiten gefunden haben, sie zu sehen und zu stehlen.

Wir können die Passwörter auch nicht einfach in einen cleveren Code umschreiben und glauben, dass wir die einzigen sind, die wissen, wie man den Code übersetzt, weil das das immer noch nicht garantiert Entschlossene Angreifer können den Code nicht herausfinden und er schützt auch nicht vor Angriffen innerhalb unserer Organisation, wie z. B. betrügerischen Ex-Mitarbeitern.

Um dies zu lösen, haben wir muss einen Einweg-Passwort-Hash verwenden. Ein Passwort-Hash ähnelt der Verwendung eines Codes, nur dass er nicht dekodiert werden kann. * Auf diese Weise kennt nur der Benutzer sein Passwort. Wir speichern nur den Hash des Passworts und überprüfen ihn, wenn sich der Benutzer anmeldet. Dies schützt unsere Benutzer und verringert unsere Haftung im Falle eines Datenverstoßes, der schwerwiegende Auswirkungen haben kann. [Beispiele für Unternehmen einschließen, die wegen unsicherer Kennwortspeicherung verklagt wurden]

* [Ich weiß, dass dies nicht unmöglich ist, aber wahrscheinlich braucht der Laie nicht so viel Detail.]

Warum hat das nicht mehr Stimmen? Außerdem sollten Sie wahrscheinlich hinzufügen, dass ein böswilliger interner Benutzer (sagen wir, der zwielichtig aussehende Typ im Flur) auf sie zugreifen und sie dann verwenden oder, schlimmer noch, verkaufen könnte, wenn die Passwörter im Klartext gespeichert sind.
Ich habe versucht, diese einfache Sprache zu verwenden, um meiner Frau das Passwort-Hashing zu erklären. Sie blieb beim Konzept einer Einwegfunktion hängen. Irgendwelche Ideen zur einfachen Sprache, um das zu erklären?
@Nomic Eine Einwegfunktion kann als die Funktion erklärt werden, die einen Personenschatten aus 1000 Winkeln erzeugt, indem das gesamte Erscheinungsbild dieser Person als Eingabe verwendet wird. Sie können anhand des Aussehens der Person vollständig bestimmen, wie ein Personenschatten aussehen wird, aber das Gegenteil ist schwieriger. Das Erzeugen einer 3D-Form, die aus mehreren Richtungen genau die gleichen Shaows erzeugt, würde sicherlich eine Menge Scultping und Überarbeiten erfordern (obwohl ein 2D-Ausschnitt für einen einzelnen Winkel funktionieren würde). Um Zugriff zu erhalten, müssen wir die 3D-Form berechnen, da nur eine 3D-Form vorliegt wird als Eingabe akzeptiert. Es reicht nicht aus, alle Schatten zu kennen.
@Nomic Das Ausprobieren ist eine hervorragende Idee! Allens Analogie ist wirklich gut; Ich würde empfehlen, über einfache Sprache den Einweg-Hash auszuarbeiten, aber zum Spaß hier ist mein Versuch einer einfachen Sprache: Ein Einweg-Passwort-Hash nimmt Text und führt clevere Berechnungen durch, damit er sich in einen verwandelt ein sehr langes und unverständliches Durcheinander von Buchstaben und Zahlen. Es unterscheidet sich von der Verwendung eines Codes, da dieser nicht wieder in die ursprüngliche Eingabe umgewandelt werden kann.
@Allen Ich mochte die Einfachheit Ihres ersten Kommentars, aber so oder so ist der Schatten eine großartige Analogie
#6
+10
Dennis Jaheruddin
2014-07-18 19:29:17 UTC
view on stackexchange narkive permalink

Alle Erklärungen sind etwas lang, hier eine kurze:

Einige Leute, die sich nicht an ihre Banknadel erinnern können, haben eine Notiz in ihrer Brieftasche.

Wenn ein Dieb oder ein Aquaintence in die Brieftasche schauen würde, hätte er ein Problem, es sei denn, die Stecknadel ist so geschrieben, dass er sie nicht lesen kann.

Hashing bedeutet im Grunde, Text so zu schreiben dass niemand sonst es lesen kann.

Könnte erweitert werden, um greifbarer zu machen, wie Sie eine Stecknadel so schreiben würden, dass niemand anderes sie verstehen würde.
Upvote, weil es eine nette schnelle Analogie ist, die die Wichtigkeit verdeutlicht, aber die Implikation ist, dass Sie die PIN aus der Notiz wiederherstellen können, wenn Sie wissen, wie der Eigentümer sie lesen kann, was eher Verschlüsselung als Hashing impliziert.
So sehr ich die Einfachheit mag, diese Analogie erfasst nicht die Idee, dass Hashing ein Einwegprozess ist. Es hängt also davon ab, wie sehr Sie denken, dass der Laie das verstehen muss.
Sie verwechseln Hashing mit Verschlüsselung. Wenn Sie das Passwort lesen können, haben Sie die privaten Daten Ihres Benutzers nicht geschützt und sind einem hohen rechtlichen Risiko ausgesetzt.
@nealmcb Mir ist klar, dass dies nicht das Hashing erklärt, sondern den Sinn des Hashing. Als solches glaube ich, dass es die Frage beantwortet.
Der Unterschied zwischen Hashing und Verschlüsselung ist hier entscheidend. Durch die Verschlüsselung können Sie Informationen schützen und später wiederherstellen. Dies ist ein großer Fehler für Websites. Das Verschlüsseln Ihrer PIN in Ihrer Brieftasche ist sinnvoll (vorausgesetzt, Sie haben einen Computer oder ein Verschlüsselungsschema für die Gehirnleistung). Das Hashing Ihrer eigenen Stecknadel ist sinnlos: Wenn Sie den Hash in Ihre Brieftasche stecken, können Sie sich nicht mehr an Ihre Stecknadel erinnern. Und das Hashing eines Bank-Pins schützt ihn nicht einmal, da die Pins so kurz sind - der Angreifer muss nur alle möglichen 4-stelligen Zahlen hashen und mit dem Hash vergleichen (was schnell ist, selbst wenn es gesalzen ist).
#7
+7
Tim S.
2014-07-18 23:06:52 UTC
view on stackexchange narkive permalink

Stellen Sie sich vor, Sie sind der Türsteher in einem Club. Um zu wissen, ob Sie Personen hereinlassen sollen, haben Sie ein Codebuch mit Namen / Aliasnamen von Personen (einige Personen bevorzugen es, diskret zu sein und sind nur bekannt durch ein Alias) und ihre eigenen privaten Passwörter; Sie können an ihrer Stimme oder ihrem Aussehen nicht erkennen, dass Personen sind oder nicht, von denen sie sagen, dass sie sie sind (es gibt zu viele Personen, und aufgrund der Aliase sind ID-Überprüfungen ein No-Go), also müssen Sie einfach gehen aus dem Buch (der Webserver kann nicht erkennen, dass Sie die falsche Person sind) . Die Leute müssen Ihnen sowohl ihren Namen als auch ihr Passwort mitteilen, um eintreten zu können. Wenn es nicht zu Ihrem Buch passt, werden sie abgewiesen.

Wenn jemand ein Bild von Ihrem Codebuch (Ihre Datenbank ist durchgesickert) , sie können sich als jeder ausgeben, den sie möchten , ohne dass Sie erkennen können, dass sie lügen. Einige Ihrer Kunden verwenden auch den gleichen Namen und das gleiche Passwort in ihrer Bank (die Kassierer haben, die genau wie Sie mit Codebüchern arbeiten), sodass ihnen auf diese Weise Geld gestohlen wird. Sie würden dann entlassen, weil Sie einen so großen Verstoß zugelassen haben, den Club sehr schlecht aussehen lassen und Geld kosten.

Glücklicherweise können Sie eine Black Box (Hash-Funktion) kaufen. , die ihren Namen (Salz) und ihr Passwort annehmen und Ihnen eine lange, zufällig aussehende Zahl (Hash) geben, die für immer gleich ist ein Vorname und ein Passwort, die sich für jede andere Kombination aus Name und Passwort unterscheiden. Anstelle Ihres Codebuchs mit [Name und Passwort] können Sie jetzt auch [Name und Nummer] enthalten! Wenn eine Person einsteigen möchte, teilt sie Ihnen ihren Namen und ihr Passwort mit, Sie geben dies in Ihre Blackbox ein und Sie suchen ihren Namen in Ihrem Codebuch, um zu überprüfen, ob die Nummer, die Sie von Ihrer Blackbox erhalten haben, mit der aufgezeichneten übereinstimmt. P. >

Wenn jemand ein Bild von Ihrem Codebuch bekommt, kann er immer noch nicht hineinkommen! Er kann nicht einmal erkennen, ob die Hälfte Ihrer Leute dasselbe Passwort verwendet. weil jede [Name und Passwort] Kombination, die in die Black Box eingegeben wurde, einzigartig war. Sie haben eine Blackbox wie Ihre und können einen bestimmten Namen und zufällige Passwörter eingeben, bis sie die richtige Nummer gefunden haben. Dies müssen sie jedoch für jede Person einzeln tun.

Wenn Sie feststellen, dass dies der Fall ist Durchgesickert, sollten Ihre Kunden immer noch ihre Passwörter ändern, um maximale Sicherheit zu gewährleisten, aber die Angreifer werden es nicht leicht haben, hineinzukommen.

Dieses Codebuch ist in Blindenschrift geschrieben?
Ja. ;) Ich habe eigentlich darüber nachgedacht, das einzutragen, aber es tut weh, wenn "jemand einen Blick auf / ein Bild Ihres Codebuchs wirft". Wenn es hilft, ist das Buch in Blindenschrift geschrieben, aber mit deutlich sichtbaren Punkten, und alles auf einem Blatt Papier. (QR-Code Braille?)
Oder wenn Sie möchten, können Sie sehen, aber der Club ist ein Maskerade-Club, in dem jeder beim Betreten Masken trägt. Und ... Maskerade ... Banken existieren in diesem Universum. Hör auf, Fragen zu stellen! ;)
@PaŭloEbermann Ich habe den blinden Teil entfernt. Am Ende entschied ich, dass es der Analogie nicht viel hinzufügte und sie schwächte.
#8
+5
The Spooniest
2014-07-20 04:40:27 UTC
view on stackexchange narkive permalink

Erklären Sie es in Bezug auf Verteidigungslinien.

Natürlich werden Sie alles tun, um sicherzustellen, dass Ihr Code sicher ist. Tatsache ist jedoch, dass Ihr Server nicht nur den von Ihnen geschriebenen Code ausführt und Sie keine Kontrolle über den von anderen Personen geschriebenen Code haben. Selbst wenn der gesamte andere Code auf dem Computer Open Source ist, müssten Sie weitere 2-3 Vollzeitentwickler einstellen, um die Verantwortung für Ihre eigenen Zweige zu übernehmen. Da - wir machen uns nichts vor - diese ganze Sache eine Kostensenkungsmaßnahme sein soll, ist dies kein praktikabler Weg.

Selbst wenn Sie absolutes Vertrauen in Ihren eigenen Code hätten, würde dies der Fall sein Immer noch viel Platz, damit etwas schief geht. Sie müssen daher sicherstellen, dass auch dann, wenn ein Angreifer in den Computer eindringt, Ihre Kennwörter weiterhin sicher sind. Hier kommt "Hashing" ins Spiel (in Anführungszeichen, weil die richtigen Algorithmen, die heutzutage verwendet werden sollen, per se nicht wirklich Hashing -Algorithmen sind, aber es ist immer noch ein nützlicher Sammelbegriff)

In militärischer Hinsicht ist dies im Wesentlichen, wie (und warum) Sie mehrere Verteidigungslinien einrichten. Kein General bringt das gesamte Militär an den gleichen Ort, weil Sie die Möglichkeit berücksichtigen müssen, dass etwas, das Sie nicht vorausgesehen haben, es ermöglicht, Ihre Frontlinien zu besiegen oder zu umgehen. Hashing ist Ihre Heimwache: Das, was Ihre Passwörter schützt, wenn alles andere fehlgeschlagen ist. Sie hoffen, dass dies niemals benötigt wird, aber die Kosten dafür, es nicht zu haben, wenn Sie es brauchen, sind einfach zu hoch: Klagen im Wert von mehreren Millionen Dollar sind nur der Anfang.

#9
+4
Ken Clubb
2014-07-18 23:23:37 UTC
view on stackexchange narkive permalink
  1. Erklären Sie, dass Passwörter ständig gestohlen werden, und wenn dies passiert, sind die Unternehmen WIRKLICH verlegen und offen für Klagen, wenn die Passwörter im Klartext vorliegen.
  2. Erklären Sie, dass Hashing wirklich einfach ist Heute tun.
  3. Nun zur Analogie:
  4. ol>

    Die beste Analogie einer Einweg-Hash-Funktion zu Nicht-Technikern besteht darin, nur eine Zahlensuche zu verwenden Analogie - vergessen Sie die komplexe Kryptographie. Wenn ein Benutzer Ihnen ursprünglich ein Kennwort gibt, weisen Sie dem Kennwort mithilfe einer Blackbox eine eindeutige Nummer zu und speichern die Nummer als Kennwort des Benutzers anstelle des ursprünglichen Kennworts.

    Wenn der Benutzer Ihnen später erneut ein Kennwort zur Authentifizierung gibt, geben Sie das angegebene Kennwort an die Blackbox weiter und erhalten eine Nummer zurück. Jetzt können Sie diese Nummer mit der zuvor gespeicherten Nummer vergleichen. Wenn die beiden Nummern übereinstimmen, sind die Passwörter identisch. Wenn die beiden Nummern nicht übereinstimmen, sind die Passwörter nicht identisch.

    Jedes eindeutige Passwort Die in die Box übergebene Nummer erhält eine eigene eindeutige Nummer, und jedes Mal, wenn dasselbe Passwort in die Blackbox eingegeben wird, wird dieselbe Nummer ausgegeben.

    Die Art und Weise, wie die Blackbox die Nummernsuche durchführt, ist sehr bekannt und alle Probleme mit der Black Box werden von der Branche behoben - alle Schwachstellen werden von der Branche behoben - IHR Unternehmen ist nicht verantwortlich, wenn es ein Problem mit der Black Box gibt.

    Schließlich, wenn die Die Nummer wird aus der Unternehmensdatenbank gestohlen. Die bekannte Black Box funktioniert nicht umgekehrt. Sie können keine gestohlene Nummer nehmen und das Passwort zurückerhalten (vorausgesetzt, das ursprüngliche Passwort war sicher).

#10
+4
Aki
2014-07-18 17:14:33 UTC
view on stackexchange narkive permalink

Erklären.

  • Menschen sind Menschen, egal wie modern sie sind; Dort gibt es Passwörter wie Geburtsdatum oder Name der Freundin / des Freundes / des Haustieres usw. usw.

Es besteht also die Gefahr, das Passwort im Klartext zu speichern. Jeder kann es lesen.

  • Hashing hilft, sie für Menschen (einschließlich loyaler Systemadministratoren) unlesbar zu machen.

Sobald ein Passwort gehasht wurde, ist es praktisch unmöglich zurück zu holen. Es besteht also keine Angst, dass Ihr Passwort von jemandem gestohlen wird. Selbst wenn jemand den Hash bekommt, ist er nutzlos.

  • Wir können sagen, wenn das Passwort eine "Frucht" ist, dann ist es "Saft". Der Saft reicht also aus, um das Benutzerkennwort zu überprüfen, wenn er / sie versucht, sich anzumelden.

Nachteil des Kennwort-Hashing ist : Niemand kann das Kennwort abrufen Originalpass. In einem solchen Fall muss das System den Benutzer auffordern, Neues Passwort

einzugeben.

Was imo überhaupt kein Nachteil ist. Dies sollte Standard sein.
Ich denke, es besteht keine Notwendigkeit für eine Analogie. Erklären Sie, was die Vorteile von Hash wirklich sind. Der einzige Weg: Es ist einfach, das Passwort zu hashen und festzustellen, ob ein Hash übereinstimmt. Es ist fast unmöglich, Hash zu verwenden, um das Passwort zu finden. Und Benutzer werden nach dem Passwort gefragt, nicht nach dem Hash.
@Martijn Dies ist ein Nachteil für den Benutzer.
Ich bin immer noch anderer Meinung. Es sollte allgemein bekannt werden, dass Sie Ihr Passwort niemals abrufen können. Auf diese Weise sollten Sie sich Sorgen machen, wenn Sie Ihr Passwort zurückerhalten.
@BrianOrtiz Warum sollte es einen Benutzer interessieren, wenn das Passwort, das Sie ihm geben, ein neues oder ein altes Passwort ist? Sie erinnern sich offensichtlich nicht daran, was es vorher war, und haben es nirgendwo gespeichert. Nach allem, was sie wissen, ist das neue Passwort, das sie gerade gewählt haben, mit dem alten identisch.
#11
+4
supercat
2014-07-19 22:44:51 UTC
view on stackexchange narkive permalink

Die grundlegendste Antwort, die ich noch nicht direkt gesehen habe, ist, dass die Handlungen von Personen, die in der Lage wären, ein Passwort zu entdecken, nicht zuverlässig von den Handlungen ihres rechtmäßigen Eigentümers unterschieden werden können. Wenn man nachweisen möchte, dass der rechtmäßige Eigentümer entweder eine Aktion ausgeführt hat oder das Passwort durch eine eigene Aktion einer nicht autorisierten Person zugänglich gemacht hat, muss man sicherstellen, dass der rechtmäßige Eigentümer niemals etwas tun muss, das es anderen ermöglichen würde, dies zu bestimmen das Passwort.

Wenn Freds Passwort in einer Datenbank auf eine Weise gespeichert wird, die nicht bis zur Wiederherstellung verschlüsselt ist, könnte Fred jeder Behauptung eines Fehlverhaltens entgegenwirken, indem er behauptet, sein Passwort sei möglicherweise von jemandem mit verwendet oder durchgesickert Zugriff auf die Passwortdatenbank. Wenn keine spezielle Hardware zum Speichern von Passwörtern verwendet wird , gibt es keine Möglichkeit, Freds Gegenanspruch zu widerlegen.

Beachten Sie, dass Fred sein Passwort aus Sicherheitsgründen niemals einem anderen aussetzen sollte als manipulationssichere Geräte, denen er vertrauen kann. Andernfalls besteht die Gefahr, dass das Gerät, in das Fred sein Passwort eingibt, so manipuliert wird, dass das nicht verwaschene Passwort an einen Gegner weitergegeben wird.

Ja, das ist die grundlegendste Antwort. Dies ist jedoch keine Analogie und nicht sehr nützlich, um jemandem zu erklären, der es bereits nicht wusste.
Vielleicht war meine Antwort etwas ausführlich, aber die Idee "Wenn Ihr Systemadministrator auf die Passwörter von Personen zugreifen kann, ist jeder Vorwurf des Fehlverhaltens gegen andere Personen ein von ihm mit dem Administrator gesagtes" sollte ziemlich verständlich sein.
#12
+3
Malcolm
2014-07-18 23:34:21 UTC
view on stackexchange narkive permalink

Stellen Sie sich vor, Sie sind Scrooge McDuck. Sie haben Ihre Geldstapel schon eine Weile in einem riesigen Tresor aufbewahrt, aber es gibt ein Problem damit: Wenn ein Dieb jemals Zugang zum Tresor erhält, geht Ihr gesamtes Geld auf einmal verloren! Das ist nicht gut. Also, kluge Ente, die Sie sind, beschließen Sie, Ihr Geld in viele kleinere Stapel aufzuteilen und jeden in einen eigenen Tresorraum zu legen. Wenn der Dieb jemals Zugang zu einem Tresor erhält, geht nur ein kleiner Teil Ihres Geldes verloren, und Sie können den kompromittierten Tresor problemlos ersetzen. Viel besser! Außer jetzt haben Sie ein neues Problem: Wie können Sie sich an die Kombinationen all dieser verschiedenen Gewölbe erinnern? Sie können nicht einfach für jeden die gleiche Kombination verwenden, denn wenn der Dieb sie jemals in die Hände bekommen würde, hätte er Zugriff auf Ihr gesamtes Geld, und Sie wären nicht besser dran, als wenn Sie es einem Riesen überlassen hätten Stapel!

Sie beschließen, einfach alle Kombinationen (zusammen mit dem Tresor, zu dem jeder geht) auf einen kleinen Zettel zu schreiben und das Papier dann in einen eigenen, separaten Tresor zu legen. Jetzt müssen Sie sich nur noch an eine Kombination erinnern, aber Ihr Geld wird immer noch getrennt aufbewahrt. Dies ist eine Verbesserung, aber immer noch problematisch, denn wenn es einem Dieb jemals gelingen würde, den Safe mit dem darin enthaltenen Papier zu finden und zu knacken, könnte er immer noch Ihr gesamtes Geld nehmen. Du willst nicht, dass das jemals passiert!

Also, was machst du? Nun, die ideale Lösung wäre, die Kombinationen in eine Art Code zu schreiben. Sie möchten einen Code, mit dem ein Dieb nicht alle ursprünglichen Kombinationen zurückerhalten kann, den Sie jedoch weiterhin verwenden können, um Zugriff auf Ihr Geld zu erhalten. Leider gibt es in Tresoren keine Möglichkeit, dies für Geld zu tun. Glücklicherweise ist für kennwortgeschützte Benutzerkonten möglich, da wir die Kennwörter unserer Benutzer nicht kennen müssen - wir müssen nur wissen, dass sie sie kennen.

Wenn Sie Ihr Geld in einem riesigen Safe aufbewahren, haben Sie ein einziges Hauptkennwort für Ihr gesamtes System. Wenn Sie Geld in verschiedenen Safes aufbewahren und alle Kombinationen aufschreiben, müssen Sie die Daten Ihrer Benutzer in passwortgeschützten Konten getrennt aufbewahren und dann alle Passwörter im Klartext an einem einzigen Ort aufbewahren: solange ein Angreifer weiß oder erraten kann, wo sich dieser Ort befindet ist, es ist nicht wirklich anders als ein einziges Master-Passwort zu haben. Sie benötigen eine Möglichkeit, Ihre Kennwortliste so zu codieren, dass Sie sie weiterhin verwenden können, um zu überprüfen, ob ein Benutzer das richtige Kennwort hat , und gleichzeitig sicherzustellen, dass ein Angreifer das Kennwort nicht verwenden kann Liste, um die Passwörter selbst zurückzubekommen . Kurz gesagt, das macht Hashing.

Lustigerweise wird in einer Episode gezeigt, dass Scrooges Geldbehälter ein triviales Passwort hat.
#13
+2
Briguy37
2014-07-21 21:43:01 UTC
view on stackexchange narkive permalink

Angenommen, Ihre Datenbank mit Kennwörtern ist durchgesickert oder gestohlen:

Wenn Kennwörter im Klartext vorliegen, gehören alle Ihre Kennwörter uns.

Wenn Kennwörter gehasht werden, alle Passwörter befinden sich immer noch in einem gemeinsam genutzten Banktresor, der geknackt werden muss.

Wenn Passwörter gehasht und gesalzen werden, befindet sich jedes Passwort in einem eigenen privaten Banktresor.

Wenn jedoch jedes Kennwort ein eigener Tresor ist, ist ein schwaches Kennwort ein schwacher Tresor.Mit dem "Shared Bank Vault" wendet die Bank zumindest einen hohen Sicherheitsstandard auf alle Passwörter an.Das Beste ist, beides anzuwenden: Dann haben schwache Passwörter den gemeinsamen Schutz und starke Passwörter einen zusätzlichen eigenen Schutz.
#14
  0
Kaz
2014-07-24 02:41:18 UTC
view on stackexchange narkive permalink

Für Hashing-Funktionen findet sich im Bereich Fußball oder Automobile keine fertige Analogie. Das Beste, was wir tun können, ist, die tatsächlichen Fakten zu verschütten.

Lieber Chef,

In einer perfekten Welt wären Benutzer sicherheitsbewusst und würden niemals dasselbe (oder sogar ein ähnliches) verwenden ) Passwort für zwei oder mehr verschiedene Sites oder Dienste. In dieser perfekten Welt hätte ein Passwort für einen Angreifer wenig Wert. Nach dem Kompromittieren der Benutzerdatenbank und dem Erlernen der Kennwörter wären diese Kennwörter nicht nützlich, um Zugriff auf andere Systeme zu erhalten.

In der realen Welt verwenden Benutzer Kennwörter erneut, sodass die Geheimhaltung von Kennwörtern weiterhin bestehen bleiben muss Wird auch dann geschützt, wenn ein System verletzt wurde, um den Schaden zu begrenzen.

Hashing hilft beim Schutz von Passwörtern, da die einzige Möglichkeit, ein Passwort aus dem Hash zu erhalten, eine Brute-Force-Berechnung ist, die Zeit in Anspruch nimmt. Diese Berechnung bricht zuerst schwache Passwörter, die kurz sind oder auf Wörterbuchwörtern und allgemeinen Phrasen basieren. Es dauert viel länger, sichere Kennwörter zu knacken, aber wenn genügend Zeit zur Verfügung steht, fallen auch diese.

Da es jedoch einige Zeit dauert, die gehashten Kennwörter zu knacken, neigen die Benutzer des kompromittierten Systems dazu, sie wiederzuverwenden Kennwörter oder ähnliche Kennwörter haben möglicherweise genügend Zeit, um gewarnt zu werden und ihre Kennwörter auf anderen Systemen zu ändern, bevor der Angreifer versucht, auf ihre Konten zuzugreifen. (Diejenigen mit sehr schwachen Passwörtern haben leider wenig oder gar keine Zeit, da schwache Passwörter sehr schnell aus Hashes "geknackt" werden können. Der Schutz dagegen sind Schutzmaßnahmen im System, die Benutzer daran hindern, schwache Passwörter zu verwenden.)

Ohne Hashing kann der Angreifer sofort auf andere Systeme zugreifen, nachdem er die Passwörter aus dem gefährdeten System gestohlen hat. Bis die Administratoren überhaupt von dem Verstoß erfahren, wurde bereits auf andere Systeme zugegriffen, zumindest für diejenigen Benutzer, die Kennwörter wiederverwenden.

Es gibt eine zweite Bedrohung: den Schleichzugang. Dies betrifft auch Benutzer, die Kennwörter nicht wiederverwenden. Angenommen, die Kennwortdatenbank eines Systems ist durchgesickert, dieses Ereignis bleibt jedoch unentdeckt. Der Angreifer kann die Passwörter verwenden, um nach dem Verstoß monatelang oder jahrelang heimlich auf das System zuzugreifen. Der Angreifer hat nicht nur Informationen gestohlen, die zum Zeitpunkt des Vorfalls aktuell waren, sondern kann auch weiterhin Informationen stehlen, indem er sich einfach bei den Konten anmeldet, für die er Kennwörter hat, solange sich diese Kennwörter nicht ändern. P. >

Hashed Passwörter schützen vor dieser Bedrohung, insbesondere in Kombination mit einer Richtlinie für regelmäßige Passwortänderungen und sichere Passwörter. Hashed Passwörter, die stark sind, stellen sicher, dass der Angreifer eine lange Berechnung durchführen muss, um ein Passwort aus dem Hash zu ermitteln. Die Kennwortänderungsrichtlinie stellt sicher, dass das erkannte Kennwort zum Zeitpunkt dieser Berechnung wahrscheinlich unbrauchbar ist, da es geändert wurde.

#15
  0
keshlam
2014-07-25 10:48:00 UTC
view on stackexchange narkive permalink

Analogie: Als Schlosser kann ich (mit Erlaubnis der Kunden) Aufzeichnungen darüber führen, was ich für sie getan habe, einschließlich der Details ihrer Schlüssel. Aber das birgt das Risiko, dass in meinen eigenen Laden eingebrochen und die Liste gestohlen wird (oder dass ein böser Angestellter dies tut). In diesem Fall könnte der Gauner Schlüssel für viele Häuser herstellen, und ich wäre dafür verantwortlich, dass ich dies nicht geschützt habe Informationen besser.

Die Lösung für Schlüssel besteht darin, diese Schlüsselinformationen NIEMALS im Klartext zu speichern. Speichern Sie es verschlüsselt und notieren Sie niemals die Informationen, die zum Dekodieren dieser Daten erforderlich sind. Wenn jemand die verschlüsselte Liste stiehlt, kann er damit keinen Schaden anrichten.

Für einen Computer würde "niemals aufschreiben" natürlich bedeuten, dass die Passwörter nicht entschlüsselt werden können. Aber wir können dieses Problem lösen, indem wir ein System schaffen, in dem wir sie nicht wirklich dekodieren müssen. Stattdessen nehmen wir das vom Benutzer eingegebene Passwort, codieren es und vergleichen die codierte Version mit dem von uns gespeicherten codierten Passwort. Wenn sie übereinstimmen, hat der Benutzer das richtige Passwort eingegeben. Es gibt "Codes" (kryptografische Hashes), die das Codieren, aber nicht das Decodieren ermöglichen, so dass dies respektabel sicher gemacht werden kann.

Hashed Passwortlisten können manchmal noch geknackt werden, aber es ist enorm teurer, dies zu tun - - und ebenso wichtig ist, dass Sie nachweisen können, dass Sie angemessene Anstrengungen unternommen haben, um die Daten der Benutzer zu schützen, sodass Ihre Haftung viel geringer ist.

#16
  0
otus
2014-07-22 15:59:41 UTC
view on stackexchange narkive permalink

Analogiezeit:

  1. Das Speichern von Klartextkennwörtern entspricht dem Entsperren Ihres Hauses.
  2. Das Verschlüsseln der Kennwortdatenbank entspricht dem Speichern des Schlüssels unter der Fußmatte.
  3. Das Hashing von Passwörtern entspricht der Verwendung einer dreistelligen Nummernsperre, die von allen Benutzern gemeinsam genutzt wird.
  4. Durch das Löschen der Passwort-Hashes erhält jeder Benutzer seine eigene Nummernsperre.
  5. PBKDF gibt diese Nummernsperren mehr Ziffern.
  6. ol>

    Niemand sollte tatsächlich Sicherheitsfragen auf der Grundlage einer Analogie entscheiden, aber diese könnten einem Laien erklären, warum es wichtig ist, Vorsichtsmaßnahmen zu treffen.

#17
-2
paj28
2014-07-22 13:04:11 UTC
view on stackexchange narkive permalink

Die technische Bedeutung von Hashing ist stark überbewertet.

Der praktische Grund für das Hashing ist, dass alle anderen dies tun. Es gilt als "Best Practice". Wenn Sie einen Verstoß haben, ist es viel einfacher, eine Position zu verteidigen, in der Sie dasselbe tun wie Ihre Kollegen. Etwas anderes zu tun, auch wenn es das Richtige ist, ist viel schwieriger zu verteidigen. Daher rate ich Websites immer, die Standard-Hashing-Methode zu befolgen, auch wenn ich denke, dass es Quatsch ist.

Warum ist die Bedeutung von Hashing also stark überbewertet? Denken wir zunächst an eine Website mit nicht gehashten Passwörtern. Die Passwörter würden im Klartext in der Datenbank gespeichert. Die Datenbank ist gesichert - auf einem physisch sicheren Server, vollständiger Festplattenverschlüsselung, Firewalls, sicherer Verwaltung und durch die Anwendungslogik auf dem Webserver geschützt. Diese Passwörter sind grundsätzlich sicher.

Warum haschen wir überhaupt? Es bietet eine letzte Verteidigungslinie. Angenommen, all diese Verteidigungen wurden vereitelt. Möglicherweise hat die NSA einen Zero-Day-Browser-Exploit verwendet, um Malware auf die Workstation des Systemadministrators zu übertragen, darauf gewartet, dass er sich bei der Datenbank anmeldet, und von dort aus die Fernsteuerung übernommen und alle Daten extrahiert. In diesem Fall erhält die NSA alle Klartextkennwörter. Und hier hilft Hashing: Wenn Sie Hashing verwenden, erhält die NSA nur die Hashes, und sie müssten einen Brute-Force-Angriff durchführen, um die Passwörter zu erhalten.

Und deshalb empfehlen die Leute Hashing. Dies ist jedoch aus drei Gründen fehlerhaft:

  1. Persönliche Daten - Die Website enthält Ihre Passwörter und auch persönliche Daten. Ob Nachrichten, Fotos, Einkaufsgeschichte. Der Grund, warum Sie in erster Linie ein Passwort haben, ist der Schutz Ihrer persönlichen Daten. Durch Hashing wird das Kennwort möglicherweise geschützt, Ihre persönlichen Daten werden jedoch nicht geschützt.

  2. Live-Erfassung - Während in der Datenbank nur Hashes gespeichert sind, wird bei jeder Anmeldung das Kennwort an den Webserver gesendet. Die NSA kann still auf dem Server sitzen und das Passwort aller erfassen. Hashing verhindert dies nicht.

  3. Wiederverwendung von Passwörtern - Es ist aus anderen Gründen wichtig, die Wiederverwendung von Passwörtern zu vermeiden. Wenn LinkedIn gehackt wird, spielt es kaum eine Rolle, ob sie mein Passwort erhalten oder nicht. Die Hacker haben bereits meine persönlichen Daten von LinkedIn. Wenn sie mein Passwort wiederherstellen, erhalten sie nur Zugriff auf LinkedIn, und sie haben bereits diese Daten.

  4. ol>

    Angesichts all dessen sind die Vorteile des Passwort-Hashing gering. Ich weiß nicht, warum die InfoSec-Community immer wieder über Passwort-Hashing spricht. Es wäre weitaus sinnvoller, sich überhaupt darauf zu konzentrieren, Datenbankverletzungen zu verhindern. Im Allgemeinen sind die Kosten für das Hashing relativ niedrig, aber es gibt eine Ausnahme: stark iterierte Hashes. Die technischen Kosten hierfür sind hoch und der Nutzen gering, so dass dieser Rat ziemlich falsch interpretiert wird. Trotzdem muss ich den Leuten raten, es zu befolgen, weil es "Best Practice" ist.

Falsch, falsch, falsch. Der Grund, warum Sie ein Passwort haben, besteht darin, die Fähigkeit zu schützen, Ihre Daten zu * kontrollieren *. Ein Datenbank-Dump ermöglicht einem Angreifer den Zugriff auf die Informationen, über die Sie jetzt verfügen. Anmeldeinformationen für Klartext geben einem Angreifer die Möglichkeit, in Ihrem Namen zu handeln, um die Daten nach Belieben zu ändern. Das einfache Hashing eines Passworts reicht nicht aus, doppeltes Hashing ist jedoch keine Seltenheit (und die Fähigkeit der NSA, verschlüsselten Datenverkehr zu schnüffeln, ist * stark * übertrieben). Und Sie können den Leuten sagen, dass sie Passwörter nicht nach Belieben wiederverwenden sollen. Sie werden es immer noch tun, und es ist immer noch die Schuld der IT, wenn es kompromittiert wurde.
@KeithS - Haben Sie Daten, um Ihre Behauptung zu untermauern, dass die meisten Verstöße schreibgeschützt sind? Sie scheinen auch den Unterschied zwischen dem Sniffing von verschlüsseltem Datenverkehr und dem lokalen Sniffing von einem kompromittierten Host nicht zu verstehen. Nicht, dass es mich überrascht, wenn Ihr Kommentar mit drei herablassenden Worten beginnt, die auf den Spielplatz gehören.
Sie behaupten selbst, dass der Angreifer, wenn er eine Kopie der Datenbank erhält, über Ihre persönlichen Daten verfügt, unabhängig davon, ob er über Ihre Anmeldeinformationen verfügt oder nicht. Die Implikation, die * Sie * bei Ihrer eigenen Aussage zu ignorieren scheinen, ist, dass sie eine Kopie davon auf ihrem eigenen System erstellen, um sie offline zu analysieren. Ohne bereits über die Anmeldeinformationen einer Person zu verfügen oder zumindest eine wirklich gute Idee zu haben, ist die anfängliche Datenverletzung * immer * schreibgeschützt. Sie schnüffeln entweder am Datenstrom oder heben den Datenspeicher auf, wenn genügend Zeit vorhanden ist, um ihn zu identifizieren. Anschließend analysieren Sie die Daten auf Anmeldeinformationen, um Zugang zu erhalten und * echten * Schaden zu verursachen.
Und ich verstehe den Unterschied zwischen dem Abhören von verschlüsseltem Datenverkehr und dem Abhören eines kompromittierten Hosts. Aus diesem Grund sind die Nachrichten, die über die NSA-Cracking-Verschlüsselungsalgorithmen fliegen, übertrieben. das ist nicht was sie tun. Wenn der Angreifer jedoch eine physische oder elektronische Präsenz auf Ihrem Computer hat, verlieren Sie. Das ist Tag 1. Die meisten Angreifer haben keinen solchen Zugriff. Wenn Sie gespeicherte Passwörter nicht schützen, nur weil eine Regierungsbehörde die Möglichkeit hat, sie zu übertragen, ist dies so, als würden Sie Ihre Haustür nicht abschließen, weil es Schlosser gibt.
@KeithS - Obwohl Details schwer zu finden sind, sind meines Erachtens die meisten Verstöße auf eine kompromittierte Datenbank oder einen kompromittierten App-Server zurückzuführen, und der Angreifer hat Lese- / Schreibzugriff. Schreibgeschützte Verstöße wie SQLi treten zwar auf, sind jedoch selten. Häufig sind Hacker nur daran interessiert, Daten (z. B. Kreditkartennummern) zu lesen, obwohl dies bei Bankensystemen anders ist. Wie auch immer, Hash weg, ich bin nicht gestört, aber ich verwende ortsspezifische Passwörter mit hoher Entropie (mit einem pw-Manager), also ist es mir egal, ob Sie es auch nicht tun.
Unabhängig vom Lesezugriff im Vergleich zum Lesen / Schreiben ... Wenn jemand nur Zugriff auf die Kennwort-Datenbank erhält, hat er nicht wirklich viel Motivation zum "Schreiben" - er könnte Sie entweder aussperren (was kommt ihm zugute?) Oder einfach Lies es. Dann können sie sich anmelden und Zugriff auf den Rest Ihres Kontos erhalten. Wenn Ihr Kennwort gehasht ist, müssen sie ein anderes Kennwort berechnen, das denselben Hashwert generiert, bevor sie sich anmelden und Zugriff auf andere Datenbits erhalten können. Das ist eine Menge Arbeit, um Informationen für einen Benutzer zu erhalten (wenn die Passwörter jedoch nicht gesalzen sind, ist es eine Menge Arbeit, um viele Benutzerinformationen zu erhalten, was sich mehr lohnt).
@Allen - Der Angreifer kann den Hash überschreiben und sich dann anmelden
#18
-5
gnasher729
2014-07-19 00:58:29 UTC
view on stackexchange narkive permalink

Was Sie dem Chef sagen sollten: "Hier ist das Problem. Ich bin ein erfahrener Softwareentwickler und sage Ihnen, dass das Speichern von unverschlüsselten Passwörtern auf einer Ebene absolut unentschuldbarer Dummheit riskant ist. Selbst das Speichern von ungesalzenen Passwörtern ist auf dieser Ebene riskant von grober Inkompetenz. Und ich habe Ihnen dies gerade gesagt. Sie können mir befehlen, unverschlüsselte Passwörter zu speichern, und ich werde es tun, aber wenn wir jemals in Schwierigkeiten geraten, werde ich jedem sagen, der hören möchte, dass es nicht daran liegt, dass ich inkompetent bin , aber weil Sie mir befohlen haben, dies gegen ernsthafte Ratschläge zu tun. An diesem Punkt verspreche ich, dass Sie persönlich verantwortlich gemacht werden und dass Sie Anwälte hinter sich haben, die jeden einzelnen Cent wollen, den Sie persönlich besitzen.

Dies führt eher dazu, dass Sie gerügt oder entlassen werden, als dass Sie den Punkt vermitteln und das Problem lösen. Dies wäre ein schrecklich dysfunktionaler Ansatz.
Oh, und ich sollte darauf hinweisen, dass es auch völlig falsch ist. Es besteht eine Wahrscheinlichkeit von ungefähr 0%, dass ein mittlerer Manager jemals persönlich für Datenverlust bei einem Verstoß haftbar gemacht wird. Vielleicht gefeuert. Nicht wahrscheinlich, aber möglich. Persönlich finanziell haftbar? Keine Chance.
Nun, wo ich wohne, weil ich dafür gefeuert werde, würde ich eine ziemlich gemütliche Siedlung bekommen.
Das ist völlig irrelevant. Die Frage ist, wie man einen nicht-technischen Chef dazu bringt, die Bedeutung des Passwort-Hashing zu verstehen. Nicht, wie man einen nicht-technischen Chef dazu bringt, Sie zu entlassen. Dies ist keine Antwort.
@gnasher729 wo wohnst du? Ich habe noch nie von einer Gerichtsbarkeit gehört, in der Entwickler nicht wegen Kompetenz entlassen werden konnten


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...