it-swarm.com.de

Wie hilft Password Salt gegen einen Rainbow-Tischangriff?

Ich habe einige Probleme, den Zweck eines Salt für ein Passwort zu verstehen. Ich verstehe, dass der primäre Zweck darin besteht, einen Rainbow-Tischangriff 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 nun nicht dem ursprünglichen Passwort, sondern einer Kombination aus Passwort und Salt zugeordnet ist. Aber sag $salt=foo und $password=bar und $hash=3858f62230ac3c915f300c664312c63f. Jetzt könnte jemand mit einer Rainbow-Tabelle den Hash umkehren und die Eingabe "foobar" einbringen. Sie könnten dann alle Kombinationen von Passwörtern ausprobieren (f, fo, foo, ... oobar, obar, bar, ar, ar). Das Abrufen des Kennworts kann einige Millisekunden dauern, ansonsten jedoch nicht viel.

Die andere Verwendung, die ich gesehen habe, ist auf meinem Linux-System. In der/etc/shadow werden die gehashten Passwörter tatsächlich mit dem Salt gespeichert . Zum Beispiel würde ein Salt von "foo" und ein Passwort von "bar" wie folgt lauten: $1$foo$te5SBM.7C25fFDu6bIRbX1. Wenn ein Hacker irgendwie in der Lage war, an diese Datei zu gelangen, kann ich nicht erkennen, wozu das Salz dient, da der umgekehrte Hash von te5SBM.7C25fFDu6bIRbX enthält bekanntlich "foo".

Vielen Dank für jedes Licht, das jemand auf diesem vergießen kann.

EDIT : Danke für die Hilfe. Um zusammenzufassen, was ich verstehe, macht das Salt das gehashte Passwort komplexer, sodass es in einer vorberechneten Rainbow-Tabelle mit sehr viel geringerer Wahrscheinlichkeit vorhanden ist. Was ich vorher missverstanden habe, war die Annahme, dass eine Rainbow-Tabelle für ALLE Hashes existiert.

215
Rich

Ein öffentliches Salt erschwert nicht Wörterbuchangriffe, wenn ein einzelnes Kennwort geknackt wird. Wie Sie bereits betont haben, hat der Angreifer sowohl Zugriff auf das gehashte Kennwort als auch auf das Salt. Wenn er also den Wörterbuchangriff ausführt, kann er beim Versuch, das Kennwort zu knacken, einfach das bekannte Salt verwenden.

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

Stellen Sie sich eine einzelne Kennwortdatei vor, die Hunderte von Benutzernamen und Kennwörtern enthält, um die erste zu verstehen. Ohne Salt könnte ich "md5 (attempt [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 Jetzt habe ich n mal so viel Arbeit zu erledigen, wobei n die Anzahl der in der Datei enthaltenen Benutzernamen und Passwörter ist.

Um den zweiten zu verstehen, muss man verstehen, was ein Rainbow-Tisch ist. Eine Rainbow-Tabelle ist eine große Liste vorberechneter Hashes für häufig verwendete Kennwörter. Stellen Sie sich noch einmal die Passwortdatei ohne Salze vor. Alles was ich tun muss, ist durch jede Zeile der Datei zu gehen, das gehashte Passwort herauszuholen und es in der Rainbow-Tabelle nachzuschlagen. Ich muss nie einen einzelnen Hash berechnen. Wenn die Suche erheblich schneller ist als die Hash-Funktion (was wahrscheinlich der Fall ist), wird dies das Knacken der Datei erheblich beschleunigen.

Wenn die Kennwortdatei gesalzen ist, muss die Rainbow-Tabelle "salt. Password" enthalten, das zuvor gehasht wurde. Wenn das Salz ausreichend zufällig ist, ist dies sehr unwahrscheinlich. Ich werde wahrscheinlich Dinge wie "hallo" und "foobar" und "qwerty" in meiner Liste häufig verwendeter, vorab gehashter Passwörter (die Rainbow-Tabelle) haben, aber ich werde keine Dinge wie "jX95psDZhello" oder "qwerty" haben "LPgB0sdgxfoobar" oder "dZVUABJtqwerty" vorberechnet. Das würde den Rainbow-Tisch unerschwinglich groß machen.

Das Salt reduziert den Angreifer also wieder auf eine Berechnung pro Zeile pro Versuch, was (im Allgemeinen) nicht zu knacken ist, wenn es mit einem ausreichend langen, ausreichend zufälligen Passwort gekoppelt ist.

234
Ross

Die anderen Antworten scheinen Ihre Missverständnisse in Bezug auf das Thema nicht auszuräumen.

Zwei verschiedene Salzverwendungen

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. In der Datei/etc/shadow werden die gehashten Passwörter zusammen mit dem Salt gespeichert.

Sie müssen immer das Salz mit dem Passwort speichern, denn um zu überprüfen, was der Benutzer mit Ihrer Passwortdatenbank eingegeben hat, müssen Sie die Eingabe mit dem Salz kombinieren, es hashen und mit dem gespeicherten vergleichen hash.

Sicherheit des Hash

Jetzt könnte jemand mit einer Rainbow-Tabelle den Hash umkehren und die Eingabe "foobar" einbringen.

[...]

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 Rainbow-Tabelle mit den üblichen Kennwö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 Rainbow-Tisch brauchen. Da Sie über den Hash nicht an das Kennwort gelangen können, berechnen Sie alle Hashes der wahrscheinlichsten verwendeten Kennwörter vor und vergleichen Sie dann Ihre Hashes mit ihren Hashes.

Qualität des Salzes

Aber sag $salt=foo

"foo" wäre eine extrem schlechte Wahl des Salzes. Normalerweise würden Sie einen Zufallswert verwenden, der in ASCII codiert ist.

Außerdem hat jedes Kennwort ein eigenes Salt, das sich (hoffentlich) von allen anderen Salt auf dem 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 irgendwie in der Lage war, diese Akte in die Hände zu bekommen, sehe ich nicht, wozu das Salz dient.

Ein Rainbow-Tischangriff immer braucht /etc/passwd (oder welche Passwortdatenbank auch immer verwendet wird), oder wie würden Sie die Hashes in der Rainbow-Tabelle mit den Hashes der tatsächlichen Passwörter vergleichen?

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

119
user3850

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

Ein guter Salt-Wert wäre also eine zufällige ganze Zahl mit 128 Bit oder mehr. Dies ist es, was Rainbow-Table-Angriffe zum Scheitern bringt. Indem Sie für jedes gespeicherte Kennwort einen anderen Salt-Wert verwenden, stellen Sie außerdem sicher, dass eine Rainbow-Tabelle, die für einen bestimmten Salt-Wert erstellt wurde (wie es der Fall sein könnte, wenn Sie ein beliebtes System mit einem einzigen Salt-Wert sind), nicht allen Zugriff gewährt Passwörter auf einmal.

87
Carl Seleborg

Noch eine großartige Frage mit vielen nachdenklichen Antworten - +1 auf 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 erstellen.

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 das Kennwort Bluescreen haben. Angenommen, es gelingt einem Hacker, dieses Kennwort zu erhalten, indem er es beispielsweise in einer E-Mail vom Benutzer an die IT-Abteilung liest. Wenn die Passwörter nicht gesalzen sind, kann der Hacker den Hash-Wert in der Datenbank finden. Passen Sie ihn einfach an, um Zugriff auf die anderen 499 Konten zu erhalten.

Durch das Salting der Passwörter wird sichergestellt, dass jedes der 500 Konten ein eindeutiges (Salt + Passwort) hat, wodurch für jedes Konto ein anderer Hash generiert wird und die Sicherheitsverletzung 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, für das nächste Betriebssystem keinen Zugriff auf die undokumentierte API hat.

35
Adam Liss

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, zufällige Salze pro Benutzer zu verwenden, damit beim Zugriff auf ein Salz die gesamte Liste der Hashes nicht so einfach geknackt werden kann.

So speichern Sie ein Passwort:

  • Erzeugen Sie mit einem CSPRNG ein langes zufälliges Salz.
  • Stellen Sie das Salt vor das Passwort und hacken 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 validieren Sie ein Passwort:

  • Rufen Sie das Salt und den Hash des Benutzers aus der Datenbank ab.
  • Stellen Sie das Salt vor das angegebene Passwort und hacken Sie es mit der gleichen 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.
15
MytyMyky

Der Grund, warum ein Salt einen Rainbow-Table-Angriff zum Scheitern bringen kann, ist, dass der Rainbow-Table für n-Bits Salt 2 ^ n-mal größer sein muss als der Table ohne Salt.

Ihr Beispiel der Verwendung von 'foo' als Salz könnte den Rainbow-Tisch 16 Millionen Mal größer machen.

Ausgehend von Carls Beispiel für ein 128-Bit-Salt wird die Tabelle dadurch 2 ^ 128-mal größer - nun, das ist groß - oder anders ausgedrückt: Wie lange dauert es, bis jemand einen so großen tragbaren Speicher hat?

12
quamrana

Die meisten Methoden zum Brechen von Hash-basierter 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 mit einer erheblichen Teilmenge möglicher Passwörter für Hashes zu ermöglichen und die umgekehrte Zuordnung zu ermöglichen. Diese Art von Angriff funktioniert, weil viele Kennwörter entweder ziemlich kurz sind oder eines von wenigen Mustern von Word-basierten Formaten verwenden.

Solche Angriffe sind in dem Fall unwirksam, in dem Kennwörter viel mehr Zeichen enthalten und nicht den üblichen Word-basierten Formaten entsprechen. Ein Benutzer, der zunächst ein sicheres Kennwort hat, 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 sich jedoch die Wirksamkeit des stärkeren zusammengesetzten Kennworts. Wie sich herausstellt, hat ein solches Schema immer noch einen Nettovorteil, da jetzt jedes Kennwort, auch die schwachen, nicht mehr für dieselbe vorberechnete Hash-/Rainbow-Tabelle anfällig ist. Stattdessen ist jeder Kennwort-Hash-Eintrag nur für eine eindeutige Hash-Tabelle anfällig.

Angenommen, Sie haben eine Website mit geringen Anforderungen an die Kennwortstärke. Wenn Sie überhaupt kein Passwort Salt verwenden, sind Ihre Hashes anfällig für vorberechnete Hashtabellen. Daher hat jemand mit Zugriff auf Ihre Hashes Zugriff auf die Passwörter für einen großen Prozentsatz Ihrer Benutzer (wie viele auch immer verwundbare Passwörter verwendet haben, bei denen es sich um a handelt) erheblicher Prozentsatz). Wenn Sie ein konstantes Kennwortsalz verwenden, sind vorberechnete Hashtabellen nicht mehr wertvoll. Daher müsste jemand die Zeit aufwenden, um eine benutzerdefinierte Hashtabelle für dieses Salz zu berechnen. Dies könnte jedoch schrittweise erfolgen und Tabellen berechnen, die immer größere Permutationen abdecken des Problemraums. Die anfälligsten Kennwörter (z. B. einfache wortbasierte Kennwörter, sehr kurze alphanumerische Kennwörter) würden in Stunden oder Tagen geknackt, weniger anfällige Kennwörter würden nach einigen Wochen oder Monaten geknackt. Mit der Zeit würde ein Angreifer für einen ständig wachsenden Prozentsatz Ihrer Benutzer Zugang zu Passwörtern erhalten. Wenn Sie für jedes Kennwort ein eindeutiges Salt verwenden, dauert es Tage oder Monate, bis Sie auf jedes dieser anfälligen Kennwörter zugreifen können.

Wie Sie sehen, erhöht sich der Aufwand, um anfällige Kennwörter bei jedem Schritt zu knacken, um mehrere Größenordnungen, wenn Sie von einem nicht gesalzenen zu einem konstanten Salz zu einem einzigartigen Salz wechseln. Ohne ein 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, und mit einem eindeutigen Salt werden die Kosten für den Zugriff auf Passwörter so hoch, dass nur der entschlossenste Angreifer Zugriff erhalten kann auf einen winzigen Teil der anfälligen Passwörter und dann nur mit großem Aufwand.

Genau das ist der Fall. Sie können Benutzer nie vollständig vor einer schlechten Kennwortauswahl schützen, aber Sie können die Kosten für die Beeinträchtigung der Kennwörter Ihrer Benutzer auf ein Maß erhöhen, das die Beeinträchtigung des Kennworts eines einzelnen Benutzers unerschwinglich macht.

10
Wedge

Ein Zweck des Saltings ist das Besiegen von vorberechneten Hash-Tabellen. Wenn jemand eine Liste mit Millionen vorberechneter Hashes hat, kann er nicht $ 1 $ foo $ te5SBM.7C25fFDu6bIRbX1 in seiner Tabelle nachschlagen, obwohl er den Hash und das Salt kennt. Sie werden es immer noch brutal erzwingen müssen.

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

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

3
recursive

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

Es ist eine bekannte Tatsache, dass viele Menschen gebräuchliche Wörter für Passwörter anstelle scheinbar zufälliger 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 Herr der Ringe Namen!;))

Also, 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, wird der Hash anders sein, so dass der Wörterbuchangriff nicht erfolgreich ist.

Hoffentlich hilft das!

1
rgargente