it-swarm-eu.dev

Warum ist die Verwendung von Salz sicherer?

Speichern des Hashs von Benutzerkennwörtern, z. in einer Datenbank ist unsicher, da menschliche Passwörter für Wörterbuchangriffe anfällig sind. Jeder schlägt vor, dass dies durch die Verwendung von Salzen gemildert wird, aber das Salz gilt als unempfindlich und muss nicht geschützt werden.

Für den Fall, dass der Angreifer das Salz hat, wie ist sein Wörterbuchangriff schwieriger geworden als zuvor? Wird der Nutzen des Salzes nicht effektiv beseitigt?

51
Jim

Salt schützt Sie nicht vor einem einzelnen Angreifer, der nur nach einem Passwort sucht. Ein Angreifer, der nur ein Passwort brechen möchte, berechnet hash(salt + guess) anstelle von hash(guess) (wenn das Passwortschema hash(salt+password) ist).

Salt hilft, wenn der Angreifer viele Passwörter knacken möchte. Dies ist normalerweise der Fall. Manchmal greift der Angreifer eine Site an und möchte in ein Konto auf dieser Site einbrechen, in ein beliebiges Konto. Ohne Salz kann der größte Teil der Arbeit des Angreifers für alle Konten verwendet werden, sodass sie jeden ihrer Versuche gleichzeitig mit allen Konten testen kann. Mit einem korrekt ausgewähltes Salt (d. H. Wenn keine zwei Konten dasselbe Salt haben) muss der Angreifer für jedes Hash-Passwort neu beginnen.

In gewissem Sinne versuchen alle Versuche zum Knacken von Passwörtern, alle Passwörter von Konten gleichzeitig zu knacken. Das liegt daran, dass Hashes vorberechnet werden können. Alles, was es braucht, ist, dass jemand eine Tabelle mit Hashes generiert - oder effizienter eine Rainbow-Tabelle - und dass die erste Arbeit an mehrere Angreifer verteilt werden kann, die sie in jeder Kontodatenbank verwenden können, die dieselbe verwendet Passwort-Hashing-Algorithmus. Auch hier macht Salz diese Vorberechnungen unbrauchbar.

Ein Brute-Force-Passwortangriff kann folgendermaßen zusammengefasst werden:

  1. Nehmen Sie eine Vorberechnung vor, die der Angreifer für nützlich hält, z. B. das Erstellen einer Rainbow-Tabelle (eine effiziente Methode zum Darstellen einer Tabelle, die Hashes allgemeinen Kennwörtern zuordnet).
  2. Für jeden der n Konten, an deren Einbruch der Angreifer interessiert ist, und für jeden der p Passwort vermutet, dass der Angreifer in sein Wörterbuch aufgenommen hat, testen Sie, ob hash(guess[i]) = hashed_password[j].

In einem naiven Ansatz erfordert der zweite Schritt n × p Hash-Berechnungen alle Vermutungen gegen alle Konten zu versuchen. Wenn der erste Schritt jedoch bereits alle möglichen Hashes berechnet hat, erfordert der zweite Schritt überhaupt keine Hash-Berechnung, sondern nur das Testen, ob jedes hashed_password befindet sich in der vorberechneten Datenbank, daher erfordert der Angriff nur n Tabellensuchen (dies kann sogar beschleunigt werden, aber wir sind bereits von n x p langsame Berechnungen¹ bis hinunter zu n Tabellensuche).

Wenn jedes Passwort ein anderes Salz hat, müsste die Vorberechnung einen Eintrag für jeden möglichen Salzwert enthalten, um hilfreich zu sein. Wenn das Salz groß genug ist, ist die Vorberechnung nicht möglich. Wenn die Vorberechnung das Salz nicht berücksichtigt, ist es nicht sinnvoll, den zweiten Schritt zu beschleunigen, da eine kryptografische Hash-Funktion “ mischt “seine Eingabe: Wenn Sie den Hash von UIOQWHHXpassword kennen, können Sie den Hash von NUIASZNApassword nicht berechnen. Selbst um ein einzelnes Konto anzugreifen, muss der Angreifer p Hash-Berechnungen durchführen, um alle Vermutungen zu versuchen. Dies wäre bereits eine Verbesserung der Suche nach einzelnen Tabellen, die ausreichen würde wenn der Angreifer ein vorberechnetes Wörterbuch hat.

¹ Ein Passwort sollte nicht als Hash wie SHA-1 gespeichert werden, sondern mit einer langsameren Hash-Funktion wie bcrypt oder scrypt oder PBKDF2 .

Ich werde jede Sicherheitsstufe für das in der Datenbank gespeicherte Passwort erläutern. Vielleicht hilft dies dabei, die Bedeutung von Salt zu verdeutlichen.

Level 1 : Passwort in clear in der Datenbank gespeichert.

Dies ist nur reine Dummheit . Aber manchmal wird bei großen Unternehmen die Datenbank kompromittiert, und überraschenderweise werden alle Passwörter klar gespeichert. Schade!

Level 2 : Passwort, das mit einem Hashing-Algorithmus gespeichert wurde.

Dies ist ein Schritt in Richtung mehr Sicherheit. Wenn ein Angreifer das Hash-Passwort erhält, kann er sich mit diesem Berechtigungsnachweis immer noch nicht beim Dienst anmelden. Er muss zuerst das Passwort mit einem Rainbow Table oder mit Brute Forcing it "auflösen". Das bedeutet, dass der Angreifer etwas mehr Arbeit benötigt, das ursprüngliche Kennwort jedoch weiterhin abgerufen werden kann.

Level 3 : Passwort, das mit einem Hashing-Algorithmus mit einem Salt gespeichert wurde.

Das fängt an interessant zu werden. Wie wir auf Level 2 gesehen haben, kann ein Angreifer, der Zugriff auf das Hash-Passwort hat, es entweder brutal erzwingen oder eine Rainbow-Tabelle verwenden. Durch Hinzufügen eines Salzes zum ursprünglichen Passwort wird die Regenbogentabelle völlig unbrauchbar , da das Salz nicht berücksichtigt wird. Es ist weiterhin möglich, die ursprüngliche Zeichenfolge mithilfe einer Rainbow-Tabelle abzurufen. Dies würde jedoch bedeuten, dass in der Rainbow-Tabelle das Kennwort + Salt vorhanden ist. Da ein Salz im Allgemeinen sehr lang ist, ist die ungerade mit einem Hash-Wert einer Zeichenfolge (40+) fast unmöglich. Die einzige verbleibende Lösung ist rohe Gewalt.

Level 4 : Passwort gespeichert unter Verwendung eines Hashing-Algorithmus mit einem Salt und einem Peper.

Dies ist sehr interessant (es ist der Grund, warum ich meine Antwort poste, da die tatsächlichen bereits interessant sind).

Ich empfehle Ihnen, einen Hashing-Algorithmus wie BCrypt, SCrypt oder PBKDF2 zu verwenden, da diese noch nicht kaputt sind und nur sehr langsam gehackt werden können. Dies verlängert die Zeit, um eines zu brechen, und anschließend eine vollständige Datenbank mit Kennwörtern.

Der Unterschied zwischen Salz und Pfeffer ist ihre Lage. Das Salz wird in der Regel in der Datenbank gespeichert, der Pfeffer befindet sich jedoch im Code. Dies mag seltsam erscheinen, aber die ursprüngliche Idee ist, dass eine Datenbank kompromittiert werden kann, nicht jedoch der Code, wodurch dem Angreifer ein Salt und eine Liste nutzloser Hash-Passwörter verbleibt. Darüber hinaus wird das Hash-Passwort noch komplexer, wodurch Regenbogentabellen völlig unbrauchbar werden (wenn wir annehmen, dass sie mit einem Salz noch ein bisschen nützlich waren!).

Für den Fall, dass nur die Datenbank kompromittiert wird, ist sogar die Brute Force nutzlos , da der Angreifer nicht nach einem Wert (dem ursprünglichen Passwort), sondern nach zwei Werten (dem Original) sucht Passwort UND der Pfeffer).

16
Cyril N.

Wenn Ihre Hashes ungesalzen sind, kann ich Hashes im Wert von ganzen Wörterbüchern erstellen und in einer Datenbank speichern (spezielle Art, die als Regenbogentabelle bezeichnet wird und für eine große Anzahl von Hashes effizienter ist). Dann muss ich sie nur nachschlagen. Grundsätzlich eine riesige Speicher-/CPU-Zeitoptimierung. Wenn ich zwei Benutzer mit demselben Hash sehe, weiß ich, dass sie dasselbe Kennwort verwenden.

Ein Salt macht den Passwort-Hash jedes Benutzers eindeutig, und wenn Sie es richtig machen, wird er wahrscheinlich auch dann eindeutig sein, wenn er dasselbe Passwort auf einer anderen Site verwendet (nicht ungewöhnlich). Daher müsste ich tatsächlich Word nehmen, Salt anwenden und Hash es, wiederholen Sie für den nächsten Eintrag im Wörterbuch.

8
ewanm89

Ungesalzene Hashes sind anfällig für Suchangriffe. Es gibt frei verfügbare Datenbanken mit Millionen von Passwort-Hashes (hauptsächlich MD5 und SHA1), mit denen der Klartext eines Hashs nachgeschlagen werden kann. Diese können auf relationalen Standarddatenbanken oder auf speziellen Datenbankformaten wie Rainbow-Tabellen basieren.

Hier ist ein Beispiel:
7c6a61c68ef8b9b6b061b28c348bc1ed7921cb53 (ungesalzen)
2d67062d67b4d0eaca31a768e901d04982de7352 (gesalzen mit dem Präfix "RxB6aE")

Eine schnelle Suche nach dem ersten Hash zeigt, dass der Klartext "passw0rd" ist. Letzteres ist jedoch nicht sehr wahrscheinlich zu finden. In dem Fall, in dem das Salz dem Angreifer nicht bekannt ist, erschwert es Wörterbuch- und Bruteforce-Angriffe.

Wenn Sie Kennwörter in einer Datenbank sichern möchten, sollten Sie beispielsweise bcrypt verwenden. Es verwendet eine große Anzahl von Iterationen eines Hash-Algorithmus, um jede Berechnung zu verlangsamen. Daher sind Bruteforce-Angriffe, Wörterbuchangriffe und das Erstellen von Regenbogentabellen höchst unmöglich.

6
Polynomial