Sie haben ein grundlegendes Missverständnis darüber, wie Regenbogentabellen funktionieren.

Eine Regenbogentabelle oder eine Hash-Tabelle wird von einem Angreifer vor einem Angriff erstellt. Angenommen, ich erstelle eine Hash-Tabelle mit allen Hashes von Zeichenfolgen mit weniger als 7 Zeichen für MD5 . Wenn ich Ihre Datenbank kompromittiere und eine Liste der Hashes erhalte, muss ich nur den Hash in der Tabelle nachschlagen, um Ihr Kennwort zu erhalten.

Mit einem Salt können Sie keine Regenbogentabelle für einen bestimmten Algorithmus vor vor einem Angriff. Ein Salt soll nicht geheim sein, Sie speichern es neben dem Hash in Ihrer Datenbank.

x = Hash (Salt + Passwort) Anschließend speichern Sie es in Ihrer Datenbank in das Format von salt + x Dies macht Regenbogentabellen und Hash-Tabellen unbrauchbar.

Verwenden Sie wie gewohnt keine eigenen, sondern verwenden Sie bcrypt , scrypt oder pbkdf2 , um alle Details zu berücksichtigen einschließlich Salzen für Sie. Siehe Wie werden Passwörter sicher gehasht?

Eine Regenbogentabelle ist eine Optimierung zum Umkehren von Hashes durch rohe Gewalt. Es funktioniert durch einen Kompromiss: Sie führen viele Vorberechnungen durch, um eine riesige Datenstruktur aufzubauen, und können dann viele Hashes schnell knacken.

Eine Regenbogentabelle hilft nur den Riss-Hashes im Suchraum, die es bedeckt. Konkret werden Regenbogentabellen für Klartexte erstellt, die aus druckbaren Zeichen und [bis zu einer bestimmten Länge bestehen. Das Grundprinzip beim Hinzufügen eines Salzes besteht darin, dass der gehashte Klartext sowohl das Passwort als auch das Salz enthält. Mit dem hinzugefügten Salz wird der Suchraum zu groß, um eine Regenbogentabelle zu erstellen.

Durch Hinzufügen eines Salzes zum Kennwort können die Kosten von daher nicht amortisiert werden ein Brute-Force-Angriff über viele Risse. Der Angreifer muss die gesamte Arbeit für jeden Hash ausführen, beginnend erst, wenn er das Salz kennt.

Bei einem Hash und einem Salz gibt es keine Möglichkeit, das Salz zu entfernen. Dies ist eine grundlegende Eigenschaft einer Hash-Funktion: Selbst wenn Sie wissen, dass zwei Zeichenfolgen zusammenhängen (z. B. wenn Sie wissen, dass das Kennwort eine Teilzeichenfolge von Kennwort + Salt ist), hilft es Ihnen nicht, Hash (Kennwort) zu finden, der Hash (Kennwort +) kennt Salz). Das Salz muss nicht vor dem Angreifer versteckt werden: Es muss eindeutig sein (und nicht vom Passwort abgeleitet sein), aber es muss nicht geheimer sein als das Hash. (Sie können ein zusätzliches geheimes Salz hinzufügen, das als Pfeffer bezeichnet wird, aber nur unter bestimmten Umständen nützlich ist.)

Das Salzen des Hash ist nur die halbe Miete. Ein weiterer Teil des sicheren Hashens von Passwörtern besteht darin, dass die Hash-Funktion langsam sein muss, da dies dem Cracker viel mehr schadet als dem Verifizierer. Rollen Sie nicht Ihre eigenen, verwenden Sie eine Methode, die von Experten überprüft wurde. Verwenden Sie bcrypt oder PBKDF2 oder scrypt. Das Implementieren der Kennwortspeicherung sollte keine Kryptografie selbst beinhalten. Rufen Sie eine Bibliotheksfunktion auf.

Für alles, was Sie über Hashing-Passwörter wissen wollten, alles, was Sie nicht über Hashing-Passwörter wissen wollten, und alles, was Sie nicht einmal über Hashing-Passwörter wissen wollten, lesen Sie Wie Sie Passwörter sicher hashen?

Sie haben grundsätzlich Recht, dass das Passwort nur verlängert wird, aber es gibt einige zusätzliche Dinge, die hinzugefügt werden. Außerdem ist das durchschnittliche Passwort nicht so lang oder sicher und das Hinzufügen von Länge "kostenlos" ist selten schlecht. Das Salz macht es so, dass ein Angreifer "Passwort" nicht einmal hashen kann und dann nach jedem Benutzer sucht, der ein Passwort von "Passwort" hat.

Stattdessen müssten sie Hashes von "password03j9834nfp-3028n408" und "passwordn0438wnvas89v5sne" und ... generieren. Dies erhöht den Schutz bei der Identifizierung unsicherer Passwörter erheblich und hat immer noch einen positiven Vorteil bei der Erhöhung der Suchschwierigkeiten Sichere Passwörter.

Wenn Sie sagen: "Könnte ein Angreifer nicht einfach eine Regenbogentabelle erstellen, dann alle Hashes konvertieren und das Salz entfernen?" Hier gibt es einige Probleme.

Das erste ist das von Kollisionen. Es ist nicht garantiert, dass eine Regenbogentabelle die ursprüngliche Eingabe erzeugt, sondern nur eine AN-Eingabe, die die gewünschte Ausgabe erzeugt. Da das Salz zu jeder Eingabe eines Benutzers hinzugefügt wird, muss der Angreifer die genaue Eingabe finden, die für den Hash verwendet wurde.

Da die genaue Eingabe gefunden werden muss, kann der Vorteil einer Regenbogentabelle genutzt werden Kollisionen gehen verloren. Außerdem wäre die Größe, die erforderlich ist, um alle möglichen Salze brutal zu erzwingen, zu groß, als dass so ziemlich jeder Angreifer sie halten könnte.

Sie können das Salz auch nicht einfach aus einem Hash entfernen, ohne herauszufinden, was die ursprüngliche Eingabe war. Sie müssten nach einem Wert suchen, der mit dem Salz endet, das dem angegebenen Hash entspricht. Dies erfordert dann, dass für jeden Salzwert in der DB eine separate Regenbogentabelle erstellt wird, und dies beeinträchtigt die Fähigkeit zur Vorberechnung, da es unmöglich ist, für jedes mögliche Salz eine Regenbogentabelle zu erstellen.

Ein einzigartiges Salz löst ein Problem - jedes Konto kann nicht gleichzeitig in einem riesigen Brute-Force-Versuch angegriffen werden.

Angenommen, Sie haben versucht, eine Regenbogentabelle mit allen druckbaren ASCII-Passwörtern zu erstellen, die 8 waren Zeichen lang ^{1 sup>. Das sind 96 sup> ~ 7,2 Millionen Milliarden (7,2 x 10 15 sup>) Möglichkeiten. Wenn Sie eine GPU hatten, die Passwörter mit einer Milliarde pro Sekunde generiert, dauert das Knacken ungefähr einen Monat (und bei 200 W mit 0,10 USD pro kWh sind es durchschnittlich etwa 200 USD; ~ 400 USD der schlechteste Fall für Ihre Stromrechnung).}

Sie finden also die Hashes jedes Kontos auf LinkedIn aus einer Art SQL-Injection heraus oder finden eine Festplatte mit einem alten Backup. Sie haben Hashes von etwa einer Million Benutzern. Wenn es sich um ungesalzene Hashes handelt, können Sie die überwiegende Mehrheit dieser Hashes in zwei Monaten mit einer GPU für etwa 400 US-Dollar Strom auflösen. Wenn sie alle einzigartig gesalzen sind und Sie alle Millionen von ihnen brechen möchten, werden jetzt 400 Millionen Dollar Strom benötigt, da jedes einzelne Salz seinen eigenen unabhängigen Angriff haben muss. Bevor Sie jetzt sagen, werde ich einen größeren Regenbogentisch bauen, der die Salze enthält. Stellen Sie fest, dass ein typisches Salz mindestens 5 Hex-Zeichen (16 ** 5) enthält, was bedeutet, dass die Erstellung Ihres Regenbogens millionenfach länger dauert Tabelle (z. B. müssen Sie 400 Millionen US-Dollar für den Strom ausgeben, um ihn zu erzeugen).

Fügen Sie nun eine Schlüsselverstärkung hinzu, bei der Sie den Prozess N-mal wiederholen, z. B. a Die dreimal iterierte Hash-Funktion wäre: Hash (Salt + Hash (Salt + Hash (Salt + Pw))) ). Anstatt jetzt eine Milliarde Hashes pro Sekunde brechen zu können, können sie jetzt eine Milliarde / N Hashes pro Sekunde brechen, sodass alle Angriffe N-mal teurer sind. (Ein typisches N ist 5000; das Brechen eines einzelnen Hashs würde also etwa 2 Millionen US-Dollar Strom kosten. Das Problem bei super großen N besteht darin, dass auf Ihren Servern mehr Rechenressourcen für die Überprüfung von Kennwortversuchen vorhanden sind.)

^{1 sup> - Dies ist nicht der effektivste Weg, um Passwörter zu knacken. Wörterbuchlisten mit Millionen zuvor verwendeter Passwörter sind viel effektiver, da viele Passwörter ziemlich schwach sind. Ich empfehle nicht, Passwörter selbst zu generieren (normalerweise mit sehr geringer Entropie) oder Passwörter wiederzuverwenden. Verwenden Sie einen Dienst wie keepassx, mit dem Sie zufällige Kennwörter für jede Site erstellen und in einer verschlüsselten Datei speichern können. Schlüsselverstärkung + einzigartiges Salz bedeutet, dass es unmöglich ist, nur die einfachsten Hashes zu brechen.}

Rainbow-Tabellen sind vorberechnete Hash-Tabellen, mit denen die Kennwörter in relativ kurzer Zeit geknackt werden, da das Nachschlagen einer Tabelle viel schneller ist als das Berechnen eines Hashs.

, wenn der Hash gefunden werden kann Passwörter Man sollte in der Lage sein, die entsprechenden Salze zu finden.

Das dem Angreifer bekannte Salz verursacht kein großes Problem, wenn der Angreifer versucht, ein einzelnes Passwort zu knacken . Das Salz macht es schwierig und zeitaufwändig, eine Liste von Passwörtern zu knacken , da das Salz für jedes Passwort unterschiedlich ist.

Aber wo speichert man das Salz? Ein Salz soll Regenbogentabellen einfach "unbrauchbar" machen, oder?

Salz wird nur in der Datenbank gespeichert und für jedes Passwort haben Sie ein anderes zufälliges Salz. Ja, das Salz macht es sehr schwierig einen Regenbogentisch benutzen. Die Regenbogentabellen werden im Allgemeinen mit gängigen Kennwörtern erstellt. Das Hinzufügen eines zufälligen Salzes macht es sehr schwierig, von einem Regenbogentisch geknackt zu werden.

Könnte ein Angreifer nicht einfach einen Regenbogentisch bauen, dann alle Hashes konvertieren und das Salz entfernen?

Vielleicht möchten Sie damit sagen, dass Sie einen Regenbogentisch mit bekannten Salzen bauen (bevor Sie den eigentlichen Angriff ausführen), weil Sie nicht einfach ein Salz aus dem Hash entfernen können. Eine Neuberechnung der Tabelle wird nicht empfohlen, da unter Berücksichtigung aller bekannten Salze die Größe der Tabelle zu groß ist. Denken Sie an einen Kompromiss zwischen Raum und Zeit. Wenn Sie die Tabellen für jeweils ein Salz erstellen, verschwenden Sie zu viel Energie. Der gesamte Zweck der Erstellung einer Regenbogentabelle besteht darin, eine Kennwortliste und kein einziges Kennwort zu knacken.

Ein weiterer sehr wichtiger Mehrwert, den das Salzen bietet, ist, dass keine zwei Benutzer einen identischen Passwort-Hash erhalten , da die Salze unterschiedlich sind. Stellen Sie sich vor, ein Angreifer kann eines der Kennwörter knacken. Wenn kein Salz verwendet wird, muss der Angreifer lediglich nachsehen, welche anderen Benutzer dasselbe Kennwort verwenden.

Erstens, warum implementieren Sie Kryptocode auf niedriger Ebene für eine Webseite? Sie würden denken, dass dies ein gelöstes Problem ist: Sie verwenden ein Framework, das Bibliotheken verwendet.

Zweitens schützt der Hash die Passwörter, falls die Hashes auslaufen. Ihre Site bietet keinen Zugriff auf die Passwortdatenbank, daher sollte diese Situation im Idealfall nicht einmal auftreten. Die Salze helfen in diesem Fall, die Kennwortdatenbank als Ganzes zu verteidigen.

Wenn sich der Angreifer auf ein einzelnes Kennwort aus dieser Datenbank konzentriert, macht dies keinen großen Unterschied. Dies erschwert die Arbeit nur in dem Sinne, dass der Angreifer das Kennwort nicht einfach aus einer Regenbogentabelle abrufen kann, indem er den Hash nachschlägt. Das brutale Erzwingen eines Passworts mit einem Salt wird nur geringfügig verlangsamt, da einige weitere Bytes gehasht werden, was einige weitere Maschinenzyklen in den Hashing-Runden kostet.

Es war einmal, dass Unix-Systeme öffentlich verfügbar waren Beim Zugriff (z. B. auf Campus-Systemen für Studenten) wurden die Passwörter links und rechts geknackt. Es gab verschiedene Gründe, warum dies einfach war, aber das Hauptproblem war ein einfaches: Die vertraulichen Kennwort-Hash-Informationen wurden in derselben Datei wie die anderen Informationsfelder über einen Benutzer gespeichert, und diese Datei, / etc / passwd war weltlesbar. Das Update besteht darin, die vertraulichen Informationen in einer separaten Datei / etc / shadow abzulegen. Presto: Damit ist das Knacken von Passwörtern durch Skriptkinder beendet, die über nicht privilegierte, legitime Konten im System verfügen.

Ebenso wird niemand Ihre Passwörter brutal erzwingen, es sei denn, Sie lassen sie auslaufen Wenn jemand nach dem Passwort eines bestimmten Benutzers sucht, kann wenig getan werden, um ihn zu stoppen.

Benutzer, die auf verschiedenen Systemen dieselben Kennwörter verwenden und diese jahrelang nicht ändern, sind immer anfällig. Sie können es salzen, pfeffern und Ketchup hinzufügen; macht keinen Unterschied.

Salze schrecken jemanden ab, der die Passwortdatenbank als Ganzes knacken und so viele verschiedene Passwörter wie möglich sammeln möchte. Salze bedeuten, dass jedes Passwort einzeln brutal erzwungen werden muss und nicht nur aus vorberechneten Tabellen abgerufen werden muss. Wenn ein Salz N Bits hat, muss die Regenbogentabellendatenbank des Angreifers zumindest idealerweise 2 ^ N-mal größer sein. Ein 32-Bit-Salt bedeutet, dass Sie eine vier Milliarden Mal größere Regenbogentabellendatenbank benötigen, um nur nach Passwörtern zu suchen.

Wenn Ihre Site nur 20 Benutzer hat, gibt es natürlich nur bis zu 20 verschiedene Salze. Ein Angreifer nimmt also das Passwortwörterbuch und hasht jeden Eintrag auf 20 verschiedene Arten mit diesen Salzen.

So schützen Salze Ihre Datenbank nicht nur vor der Suche nach Regenbogentabellen, sondern auch vor Brute-Force-Cracking um etwa den Faktor N, wobei N die Anzahl der Benutzer ist. Um N Passwörter brutal zu erzwingen, muss der Angreifer die N-fache Arbeit als Brute-Force-Passwort ausführen. (Angenommen, das Salz ist breit genug: mindestens so groß wie der Logarithmus zur Basis 2 von N. Wenn ein Salz nur beispielsweise 12 Bit breit ist, kann es nur 4096 verschiedene Salze geben, egal wie viele Benutzer es gibt.)

Ohne Salze ist dies nicht wahr. Das brutale Erzwingen einer beliebigen Anzahl von Passwörtern gleichzeitig ist so einfach wie das brutale Erzwingen eines Kennworts. Je mehr Benutzer vorhanden sind, desto höher ist die Auszahlung pro Aufwand.

Es gibt einige Faktoren beim Salzen, und Sie vermissen (mindestens) einen davon.

• Sie machen Regenbogentabellen unbrauchbar. Wenn jemand in Ihrer Passwortdatenbank nachschaut und feststellt, dass das Passwort "5f4dcc3b5aa765d61d8327deb882cf99" lautet, muss er nicht einmal eine "Regenbogentabelle" erstellen. Er kann einfach nach diesem Wert googeln und Google teilt ihm mit, dass es sich um den MD5-Hash von " Passwort". Wenn die Passwörter vor dem Einfügen in Ihre Datenbank gehasht werden, ist der Suchmechanismus "Regenbogentabelle" unbrauchbar. Sie müssen Ihr Salz nicht in der Datenbank speichern, um Regenbogentabellen unbrauchbar zu machen. Ihr Salz kann einfach immer "xxxx" oder eine andere beliebige Zeichenfolge sein. Wenn Sie nach 6a316e1fdac8a61d9c7a2ed1cba4a804 (dem md5-Hash von "xxxxpassword") googeln, erhalten Sie keine Ergebnisse.

• Wenn dies richtig gemacht wird, bedeutet das Salz im Allgemeinen, dass ein Eindringling sowohl Ihre Datenbank als auch Ihren Code, um Ihre Passwörter zu knacken. Sie könnten Ihr Passwort als "xxxx" + Passwort oder pw.substring (0,2) + "xxxx" + pw.substring (2) gehasht haben. Der Angreifer weiß nicht, wie Sie Ihre Passwörter gesalzen haben, es sei denn, er hat auch Ihren Code gestohlen. Ihr Webserver wird häufig nicht auf derselben Box wie Ihre Datenbank ausgeführt, und mit kompilierten Programmiersprachen ist Ihr Code möglicherweise auch nicht auf Ihrem Webserver verfügbar. Unabhängig davon, welche Salze Sie in Ihrer Datenbank speichern, würde ich empfehlen, auch ein langes, willkürliches, festes Salz außerhalb der Datenbank zu speichern, das vor dem Hashing zusätzlich mit dem Kennwort verknüpft wird.

• Einzigartige Salze verteuern das Cracken. Wie bereits erwähnt, können Sie, wenn Sie jedes Wörterbuchwort mit einem statischen Salt ("xxxx") hashen, die gesamte Kennwortdatenbank nach "6a316e1fdac8a61d9c7a2ed1cba4a804" durchsuchen und nach Personen suchen, deren Kennwort "Kennwort" lautet. Wenn jede Zeile ein anderes Salz verwendet, müssen Sie N Hashes ausführen, um herauszufinden, ob einer von N Benutzern das Kennwort "Kennwort" hat.

• Achten Sie beim zweiten Punkt darauf, nur ein einziges festes einfaches Salz ohne ein anderes zu verwenden. Ein Cracker könnte versuchen, beliebige Zeichenfolgen + "Passwort" zu hashen, bis er jemanden findet, dessen Passwort "Passwort" ist, und dann im Wesentlichen Ihr Salz geknackt hätte. In jeder großen Datenbank mit Kennwörtern muss mindestens ein Benutzer vorhanden sein, dessen Kennwort ein triviales Kennwort wie "Kennwort" ist.

Ich sehe, dass hier noch eine Regenbogentabelle funktioniert, allerdings mit etwas mehr Arbeit.

Wenn x der Hash-Wert für Passwort + Salz ist und Salz jedem bekannt sein kann, da es in der Datenbank gespeichert ist In den Anwendungsdateien kann ich dann immer noch eine Regenbogentabelle verwenden.

Wählen Sie Ihre Regenbogentabelle aus, fügen Sie neue Spalten hinzu, dh hashed_password_Salt für alle Hash-Werte, und führen Sie dann eine Aktualisierung für die Spalte mit dem Ergebnis für x = Hash (Passwort) durch + salt) Da in der Spalte mit den allgemeinen Kennwortzeichenfolgen bereits

vorhanden ist, wird Ihre Regenbogentabelle aktualisiert, um das Knacken von Kennwörtern mithilfe eines Wörterbuchangriffs zu behandeln.

Sombody kann mich korrigieren, wenn dies nicht der Fall ist praktikabler Weg