Wie hilft Password Salt gegen einen Regenbogentischangriff?

Ich habe einige Probleme, den Zweck eines Salt für ein Passwort zu verstehen. Nach meinem Verständnis besteht der Hauptzweck darin, einen Regenbogentischangriff zu behindern. Die Methoden, die ich gesehen habe, um dies zu implementieren, scheinen das Problem jedoch nicht wirklich zu erschweren.

Ich habe viele Tutorials gesehen, in denen vorgeschlagen wurde, das Salz wie folgt zu verwenden:

$hash =  md5($salt.$password)

Der Grund dafür ist, dass der Hash jetzt nicht dem ursprünglichen Passwort zugeordnet ist, sondern einer Kombination aus Passwort und Salt. Aber sag $salt=foound $password=barund $hash=3858f62230ac3c915f300c664312c63f. Jetzt könnte jemand mit einem Regenbogentisch den Hash umkehren und die Eingabe "foobar" finden. Sie könnten dann alle Kombinationen von Passwörtern ausprobieren (f, fo, foo, ... oobar, obar, bar, ar, ar). Es kann noch einige Millisekunden dauern, bis das Passwort abgerufen wird, aber sonst nicht viel.

Die andere Verwendung, die ich gesehen habe, ist auf meinem Linux-System. Im / etc / shadow werden die Hash-Passwörter tatsächlich mit dem Salt gespeichert . Zum Beispiel würde ein Salz von "foo" und ein Passwort von "bar" dazu führen : $1$foo$te5SBM.7C25fFDu6bIRbX1. Wenn ein Hacker irgendwie in der Lage war, diese Datei in die Hände zu bekommen, sehe ich nicht, welchen Zweck das Salz erfüllt, da der umgekehrte Hash von te5SBM.7C25fFDu6bIRbXbekanntermaßen "foo" enthält.

Vielen Dank für jedes Licht, das jeder darauf werfen kann.

EDIT : Danke für die Hilfe. Um zusammenzufassen, was ich verstehe, das Salz macht das Hash-Passwort komplexer, wodurch es viel weniger wahrscheinlich ist, dass es in einer vorberechneten Regenbogentabelle existiert. Was ich vorher missverstanden habe, war, dass ich davon ausgegangen bin, dass es für ALLE Hashes einen Regenbogentisch gibt.

Ein öffentliches Salt macht Wörterbuchangriffe beim Knacken eines einzelnen Passworts nicht schwieriger. Wie Sie bereits betont haben, hat der Angreifer Zugriff auf das Hash-Passwort und das Salt. Wenn er also den Wörterbuchangriff ausführt, kann er einfach das bekannte Salt verwenden, wenn er versucht, das Passwort zu knacken.

Ein öffentliches Salz macht zwei Dinge: Es ist zeitaufwändiger, eine große Liste von Passwörtern zu knacken, und es ist unmöglich, eine Regenbogentabelle zu verwenden.

Stellen Sie sich zum Verständnis der ersten eine einzelne Kennwortdatei vor, die Hunderte von Benutzernamen und Kennwörtern enthält. Ohne Salz könnte ich "md5 (Versuch [0])" berechnen und dann die Datei durchsuchen, um festzustellen, ob dieser Hash irgendwo auftaucht. Wenn Salze vorhanden sind, muss ich "md5 (Salz [a]. Versuch [0])" berechnen, mit Eintrag A vergleichen, dann "md5 (Salz [b]. Versuch [0])", mit Eintrag B vergleichen usw. Jetzt habe ich nmal so viel zu tun, wo nist die Anzahl der in der Datei enthaltenen Benutzernamen und Passwörter.

Um den zweiten zu verstehen, muss man verstehen, was ein Regenbogentisch ist. Eine Regenbogentabelle ist eine große Liste vorberechneter Hashes für häufig verwendete Kennwörter. Stellen Sie sich noch einmal die Passwortdatei ohne Salz vor. Ich muss nur jede Zeile der Datei durchgehen, das Hash-Passwort herausziehen und es in der Regenbogentabelle nachschlagen. Ich muss nie einen einzigen Hash berechnen. Wenn die Suche erheblich schneller ist als die Hash-Funktion (was wahrscheinlich der Fall ist), wird das Knacken der Datei erheblich beschleunigt.

Wenn die Kennwortdatei jedoch gesalzen ist, muss die Regenbogentabelle vor dem Hash "salt. Kennwort" enthalten. Wenn das Salz ausreichend zufällig ist, ist dies sehr unwahrscheinlich. Ich werde wahrscheinlich Dinge wie "Hallo" und "Foobar" und "QWERTY" in meiner Liste der häufig verwendeten, vorab gehashten Passwörter (die Regenbogentabelle) haben, aber ich werde keine Dinge wie "jX95psDZhello" oder " "LPgB0sdgxfoobar" oder "dZVUABJtqwerty" vorberechnet. Das würde den Regenbogentisch unerschwinglich groß machen.

Das Salz reduziert den Angreifer also auf eine Berechnung pro Zeile pro Versuch, die in Verbindung mit einem ausreichend langen, ausreichend zufälligen Passwort (im Allgemeinen) nicht knackbar ist.

Die anderen Antworten scheinen Ihre Missverständnisse des Themas nicht auszuräumen.

Zwei verschiedene Verwendungen von Salz

Ich habe viele Tutorials gesehen, in denen vorgeschlagen wurde, das Salz wie folgt zu verwenden:

$hash = md5($salt.$password)

[...]

Die andere Verwendung, die ich gesehen habe, ist auf meinem Linux-System. Im / etc / shadow werden die Hash-Passwörter tatsächlich mit dem Salt gespeichert.

Sie immer mit dem Passwort , das Salz speichern müssen, denn um zu bestätigen , was der Benutzer gegen Ihre Passwort - Datenbank eingegeben hat , haben Sie die Eingabe mit dem Salz zu kombinieren, es Hash und vergleichen Sie es mit dem gespeicherten Hash.

Sicherheit des Hash

Jetzt könnte jemand mit einem Regenbogentisch den Hash umkehren und die Eingabe "foobar" finden.

[...]

da der umgekehrte Hash von te5SBM.7C25fFDu6bIRbX bekanntermaßen "foo" enthält.

Es ist nicht möglich, den Hash als solchen umzukehren (zumindest theoretisch). Der Hash von "foo" und der Hash von "saltfoo" haben nichts gemeinsam. Das Ändern von nur einem Bit in der Eingabe einer kryptografischen Hash-Funktion sollte die Ausgabe vollständig ändern.

Dies bedeutet, dass Sie keine Regenbogentabelle mit den gängigen Passwörtern erstellen und später mit etwas Salz "aktualisieren" können. Sie müssen das Salz von Anfang an berücksichtigen.

Dies ist der ganze Grund, warum Sie überhaupt einen Regenbogentisch brauchen. Da Sie aus dem Hash nicht zum Kennwort gelangen können, berechnen Sie alle Hashes der am wahrscheinlichsten verwendeten Kennwörter vor und vergleichen Ihre Hashes mit ihren Hashes.

Qualität des Salzes

Aber sag $salt=foo

"foo" wäre eine extrem schlechte Salzauswahl. Normalerweise würden Sie einen zufälligen Wert verwenden, der in ASCII codiert ist.

Außerdem hat jedes Passwort ein eigenes Salz, das sich (hoffentlich) von allen anderen Salzen im System unterscheidet. Dies bedeutet, dass der Angreifer jedes Kennwort einzeln angreifen muss, anstatt zu hoffen, dass einer der Hashes mit einem der Werte in seiner Datenbank übereinstimmt.

Der Angriff

Wenn ein Hacker diese Datei irgendwie in die Hände bekommen konnte, sehe ich nicht, welchen Zweck das Salz erfüllt.

Ein Regenbogentabellenangriff benötigt immer/etc/passwd (oder welche Passwortdatenbank auch immer verwendet wird), oder wie würden Sie die Hashes in der Regenbogentabelle mit den Hashes der tatsächlichen Passwörter vergleichen?

Zum Zweck: Nehmen wir an, der Angreifer möchte eine Regenbogentabelle für 100.000 häufig verwendete englische Wörter und typische Passwörter erstellen (denken Sie an "geheim"). Ohne Salz müsste sie 100.000 Hashes vorberechnen. Selbst mit dem traditionellen UNIX-Salt von 2 Zeichen (jedes ist eine von 64 Möglichkeiten [a–zA–Z0–9./]:) müsste sie 4.096.000.000 Hashes berechnen und speichern ... eine ziemliche Verbesserung.

Die Idee mit dem Salz ist es, das Erraten mit Brute-Force viel schwieriger zu machen als mit einem normalen zeichenbasierten Passwort. Regenbogentabellen werden häufig mit einem speziellen Zeichensatz erstellt und enthalten nicht immer alle möglichen Kombinationen (obwohl dies möglich ist).

Ein guter Salzwert wäre also eine zufällige Ganzzahl von 128 Bit oder länger. Dies ist es, was Regenbogentischangriffe zum Scheitern bringt. Indem Sie für jedes gespeicherte Kennwort einen anderen Salzwert verwenden, stellen Sie außerdem sicher, dass eine Regenbogentabelle, die für einen bestimmten Salzwert erstellt wurde (wie dies der Fall sein kann, wenn Sie ein beliebtes System mit einem einzigen Salzwert sind), Ihnen nicht Zugriff auf alle bietet Passwörter sofort.

Noch eine tolle Frage mit vielen sehr nachdenklichen Antworten - +1 bis SO!

Ein kleiner Punkt, den ich nicht explizit erwähnt habe, ist, dass Sie durch Hinzufügen eines zufälligen Salt zu jedem Passwort praktisch garantieren, dass zwei Benutzer, die zufällig dasselbe Passwort gewählt haben, unterschiedliche Hashes erzeugen.

Warum ist das wichtig?

Stellen Sie sich die Passwortdatenbank eines großen Softwareunternehmens im Nordwesten der USA vor. Angenommen, es enthält 30.000 Einträge, von denen 500 den Passwort- Bluescreen haben . Angenommen, ein Hacker kann dieses Kennwort erhalten, indem er es beispielsweise in einer E-Mail des Benutzers an die IT-Abteilung liest. Wenn die Passwörter ungesalzen sind, kann der Hacker den Hash-Wert in der Datenbank finden und ihn dann einfach mit einem Muster abgleichen, um Zugriff auf die anderen 499 Konten zu erhalten.

Durch das Versalzen der Kennwörter wird sichergestellt, dass jedes der 500 Konten ein eindeutiges (Salt + Kennwort) hat, wodurch für jedes Konto ein anderer Hash generiert wird, wodurch die Verletzung auf ein einziges Konto reduziert wird. Und hoffen wir, dass jeder Benutzer, der naiv genug ist, um ein Klartextkennwort in eine E-Mail-Nachricht zu schreiben, keinen Zugriff auf die undokumentierte API für das nächste Betriebssystem hat.

Ich suchte nach einer guten Methode zum Auftragen von Salzen und fand diesen hervorragenden Artikel mit Beispielcode:

http://crackstation.net/hashing-security.htm

Der Autor empfiehlt die Verwendung von zufälligen Salzen pro Benutzer, damit der Zugriff auf ein Salz nicht die gesamte Liste der Hashes so leicht zu knacken macht.

So speichern Sie ein Passwort:

• Erzeugen Sie mit einem CSPRNG ein langes zufälliges Salz.
• Stellen Sie dem Passwort das Salt voran und hashen Sie es mit einer standardmäßigen kryptografischen Hash-Funktion wie SHA256.
• Speichern Sie sowohl das Salt als auch den Hash im Datenbankeintrag des Benutzers.

So überprüfen Sie ein Passwort:

• Rufen Sie das Salt und den Hash des Benutzers aus der Datenbank ab.
• Stellen Sie das Salt dem angegebenen Passwort voran und hashen Sie es mit derselben Hash-Funktion.
• Vergleichen Sie den Hash des angegebenen Passworts mit dem Hash aus der Datenbank. Wenn sie übereinstimmen, ist das Passwort korrekt. Andernfalls ist das Passwort falsch.

Der Grund, warum ein Salz einen Regenbogentischangriff zum Scheitern bringen kann, ist, dass für n-Salzstücke der Regenbogentisch 2 ^ n-mal größer sein muss als die Tischgröße ohne Salz.

Ihr Beispiel für die Verwendung von 'foo' als Salz könnte den Regenbogentisch 16 Millionen Mal größer machen.

In Anbetracht von Carls Beispiel eines 128-Bit-Salzes wird die Tabelle dadurch 2 ^ 128-mal größer - das ist jetzt groß - oder anders ausgedrückt: Wie lange dauert es, bis jemand einen so großen tragbaren Speicher hat?

Die meisten Methoden zum Aufheben der Hash-basierten Verschlüsselung basieren auf Brute-Force-Angriffen. Ein Regenbogenangriff ist im Wesentlichen ein effizienterer Wörterbuchangriff. Er wurde entwickelt, um die geringen Kosten des digitalen Speichers zu nutzen, um die Erstellung einer Karte einer wesentlichen Teilmenge möglicher Kennwörter für Hashes zu ermöglichen und die umgekehrte Zuordnung zu erleichtern. Diese Art von Angriff funktioniert, weil viele Passwörter entweder ziemlich kurz sind oder eines der wenigen Muster wortbasierter Formate verwenden.

Solche Angriffe sind in dem Fall unwirksam, in dem Passwörter viel mehr Zeichen enthalten und nicht den gängigen wortbasierten Formaten entsprechen. Ein Benutzer mit einem starken Kennwort ist für diesen Angriffsstil nicht anfällig. Leider wählen viele Leute keine guten Passwörter aus. Es gibt jedoch einen Kompromiss: Sie können das Kennwort eines Benutzers verbessern, indem Sie ihm zufälligen Junk hinzufügen. Anstelle von "hunter2" könnte ihr Passwort nun effektiv zu "hunter2908! Fld2R75 {R7 /; 508PEzoz ^ U430" werden, was ein viel stärkeres Passwort ist. Da Sie diese zusätzliche Kennwortkomponente jetzt speichern müssen, verringert dies die Wirksamkeit des stärkeren zusammengesetzten Kennworts. Wie sich herausstellt, hat ein solches Schema immer noch einen Nettovorteil, da jetzt jedes Passwort, auch die schwachen, sind nicht mehr anfällig für dieselbe vorberechnete Hash- / Regenbogentabelle. Stattdessen ist jeder Kennwort-Hash-Eintrag nur für eine eindeutige Hash-Tabelle anfällig.

Angenommen, Sie haben eine Site mit schwachen Anforderungen an die Kennwortstärke. Wenn Sie überhaupt kein Kennwort verwenden, sind Ihre Hashes für vorberechnete Hash-Tabellen anfällig. Daher hat jemand mit Zugriff auf Ihre Hashes für einen großen Prozentsatz Ihrer Benutzer Zugriff auf die Kennwörter (unabhängig davon, wie viele anfällige Kennwörter verwendet werden) erheblicher Prozentsatz). Wenn Sie ein konstantes Kennwort-Salt verwenden, sind vorberechnete Hash-Tabellen nicht mehr wertvoll, sodass jemand die Zeit für die Berechnung einer benutzerdefinierten Hash-Tabelle für dieses Salt aufwenden müsste. Dies könnte jedoch schrittweise geschehen und Tabellen berechnen, die immer größere Permutationen abdecken des Problemraums. Die am stärksten gefährdeten Kennwörter (z. B. einfache wortbasierte Kennwörter, sehr kurze alphanumerische Kennwörter) werden in Stunden oder Tagen geknackt, weniger anfällige Kennwörter werden nach einigen Wochen oder Monaten geknackt. Mit der Zeit würde ein Angreifer für einen immer größeren Prozentsatz Ihrer Benutzer Zugriff auf Kennwörter erhalten. Wenn Sie für jedes Kennwort ein eindeutiges Salt verwenden, dauert es Tage oder Monate, bis Sie Zugriff auf jedes dieser anfälligen Kennwörter erhalten.

Wie Sie sehen können, erhöhen Sie den Aufwand, um anfällige Passwörter bei jedem Schritt zu knacken, um mehrere Größenordnungen, wenn Sie von keinem Salz zu einem konstanten Salz zu einem einzigartigen Salz wechseln. Ohne Salt sind die schwächsten Passwörter Ihrer Benutzer trivial zugänglich. Mit einem konstanten Salt sind diese schwachen Passwörter für einen bestimmten Angreifer zugänglich. Mit einem eindeutigen Salt sind die Kosten für den Zugriff auf Passwörter so hoch, dass nur der entschlossenste Angreifer Zugriff erhalten kann zu einer winzigen Teilmenge anfälliger Passwörter, und dann nur mit großem Aufwand.

Genau in dieser Situation können Sie Benutzer niemals vollständig vor einer schlechten Passwortauswahl schützen, aber Sie können die Kosten für die Kompromittierung der Passwörter Ihrer Benutzer auf ein Niveau erhöhen, das die Kompromittierung selbst des Passworts eines Benutzers unerschwinglich macht.

Ein Zweck des Salzens besteht darin, vorberechnete Hash-Tabellen zu besiegen. Wenn jemand eine Liste mit Millionen von vorberechneten Hashes hat, kann er $ 1 $ foo $ te5SBM.7C25fFDu6bIRbX1 in seiner Tabelle nicht nachschlagen, obwohl er den Hash und das Salz kennt. Sie werden es immer noch brutal erzwingen müssen.

Ein weiterer Zweck, wie Carl S erwähnt, besteht darin, das brutale Erzwingen einer Liste von Hashes teurer zu machen. (Gib ihnen alle verschiedene Salze)

Beide Ziele werden auch dann noch erreicht, wenn die Salze öffentlich sind.

Soweit ich weiß, soll das Salz Wörterbuchangriffe erschweren.

Es ist bekannt, dass viele Menschen gebräuchliche Wörter für Passwörter anstelle von scheinbar zufälligen Zeichenfolgen verwenden.

Ein Hacker könnte dies also zu seinem Vorteil nutzen, anstatt nur rohe Gewalt anzuwenden. Er wird nicht nach Passwörtern wie aaa, aab, aac suchen ... sondern stattdessen Wörter und gebräuchliche Passwörter verwenden (wie die Namen der Herren der Ringe !;))

Wenn mein Passwort Legolas ist, könnte ein Hacker das versuchen und es mit ein paar "Versuchen" erraten. Wenn wir jedoch das Passwort salzen und es zu fooLegolas wird, ist der Hash anders, sodass der Wörterbuchangriff nicht erfolgreich ist.

Hoffentlich hilft das!

Ich gehe davon aus, dass Sie die Funktion PHP --- md5 () und $ vorangestellte Variablen --- verwenden. Dann können Sie versuchen, diesen Artikel zu lesen. Schattenkennwort HOWTO Speziell den 11. Absatz.

Wenn Sie Angst haben, Message Digest-Algorithmen zu verwenden, können Sie echte Verschlüsselungsalgorithmen ausprobieren, wie sie beispielsweise von der bereitgestellt werden mcrypt- Modul oder stärkere Message Digest-Algorithmen wie die vom mhash- Modul (sha1, sha256 und Andere).

Ich denke, dass ein stärkerer Message Digest-Algorithmus ein Muss ist. Es ist bekannt, dass MD5 und SHA1 Kollisionsprobleme haben.