it-swarm.com.de

Wie schwer wäre es, bcrypt-Hashes zu knacken, wenn das Salz unbekannt ist?

(Dies ist IMHO kein Duplikat der verknüpften Frage, da es mehr um die Unterschiede zwischen einem Salt und einem Passwort geht: Beide Variablen werden zum Generieren eines Hashs verwendet.)

Angenommen, ein Angreifer hat Offline-Zugriff auf eine Datenbank, in der Kennwörter mit bcrypt gehasht werden (kein Pfeffer hinzugefügt). Die Hashes sehen aus wie:

$2y$10$H0mRpD2XJZDguAzxTehwzunRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G

In dem das Salz ist: H0mRpD2XJZDguAzxTehwzu und der Hash ist nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G.

Der Angreifer kann keine Rainbow-Tabelle ausführen, die mit Hashes übereinstimmt. Er kann jedoch unter Verwendung des enthaltenen Salt allgemeine Kennwörter berechnen und Folgendes ausführen:

bcrypt("abcd1234", 10, "H0mRpD2XJZDguAzxTehwzu")

wird herstellen:

nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G

Und da hast du! Sie könnte alle Datenbanktests "abcd1234" durchlaufen und in Sekunden/Minuten feststellen können, welche Benutzer dieses schwache Passwort verwenden.

Was ist, wenn nur der Hash nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G ist in der Datenbank gespeichert (kein Salz)?

Wenn der Angreifer das starke Gefühl hat, dass der Benutzer "abcdefg" möglicherweise das Kennwort "abcd1234" verwendet, wie könnte er seine Theorie offline testen? Sie würde das Salz erraten müssen. Wie konnte sie das machen? Gibt es eine einfachere Methode als jede Kombination auszuprobieren? Vielleicht gibt es in diesem speziellen Fall nicht genug Motivation, es zu versuchen. Aber was ist, wenn sie den Verdacht hat, dass das System für alle Passwörter das gleiche Salz verwendet (da einige Hashes gleich sind)? Wie schwer würde es für sie sein, es zu knacken?


UPDATE

Peleus 'Antwort kommt meiner Erwartung nahe. Ich werde versuchen, es zu erweitern (korrigiere mich, wenn ich falsch liege):

Entropie:

In Bcrypt besteht ein Salt normalerweise aus 16 zufälligen Bytes (128 Bit). Wenn wir das mit einem Passwort gleicher Länge vergleichen, hat ein Salt eine größere Entropie als ein Passwort, da Passwörter normalerweise auf das beschränkt sind, was der Benutzer mit einer Tastatur eingeben kann.

Diese 16 Bytes werden in HEX codiert (unter Verwendung von Base64) und werden 22 lang. Wenn wir sie mit einem 22-stelligen Passwort vergleichen, enthält das Passwort eine größere Entropie (da es Symbole und das vollständige Alphabet enthalten kann).

Länge:

Bcrypt-Salze sind auf 16 Byte begrenzt, während Kennwörter je nach Implementierung auf 72 Byte begrenzt sein können.

Kollision:

2 verschiedene Salze erzeugen 2 verschiedene Hashes und damit die Passwörter. Irgendwann können jedoch 2 verschiedene Salze denselben Hash mit demselben Passwort erzeugen und umgekehrt. Welches ist die Wahrscheinlichkeit für jeden dieser Fälle? Das sollte ich vielleicht in crypto.SE fragen. Aber ich lasse es hier, falls jemand die Antwort darauf hat.

Design:

Der Algorithmus wurde entwickelt, um Passwörter und keine Salze zu schützen. Dies bedeutet, dass Salze von Natur aus nicht sicher sein sollen, was darauf hindeutet, dass es möglicherweise einen Weg gibt, sie zu erhalten, ohne sie brutal zu erzwingen.

Fiktiver Fall:

Wir sind an die Benutzerkennwortmethode gewöhnt, um den Zugriff auf ein System zu schützen. Aber was wäre wenn so etwas passiert (bitte nackt mit mir, es ist nur ein Beispiel)?:

Unternehmen CauseWeWantItThatWay verwendet Mikrochips, um einen eindeutigen Wert von 22 Hex-Zeichen zu speichern (zur Verwendung als Salz). Jeder Benutzer generiert insgesamt 5 Passwörter oder PIN Zahlen (jeweils 4 Ziffern, ja, sie sind faul) mit diesem eindeutigen Salt, um auf 5 verschiedene Systeme zuzugreifen.

Nehmen wir nun an, ich bin einem dieser Systeme zugeordnet und kenne eine dieser PIN -Nummern), und irgendwie habe ich Zugriff auf die Datenbank. Wenn das Salz enthalten wäre, wäre dies trivial Holen Sie sich diese PIN Zahlen, aber ohne das Salz müsste ich es knacken.

Ich weiß was du denkst. Das Unternehmen hat eine wirklich schlechte Sicherheitsimplementierung (und sie sollten in der Hölle brennen). Außerdem hätten sie stattdessen das "Salz" als Pfeffer verwenden und das Salz zufällig belassen können. Meine Frage war also, in diesem Fall wäre es dasselbe, 22-Hex-Zeichen als Pfeffer hinzuzufügen, als diese als Salz zu verwenden? Laut Peleus ist es dasselbe (es gibt also keine Abkürzungen, um das Salz zu erhalten).

Schließlich folgt nicht jeder den Empfehlungen und der Algorithmus ermöglicht es Ihnen, das Salz einzustellen, was diese Art von Szenario völlig möglich macht (obwohl nicht so wahrscheinlich oder empfohlen).

6
lepe

Ich denke, Sie haben den Zweck eines Salzes falsch verstanden, denn wenn Sie verstehen würden, was es erreichen soll, würden Sie diese Frage vielleicht nicht stellen. Der einzige Zweck besteht darin, jedem Kennwort ein Maß an Eindeutigkeit zu verleihen, um zu verhindern, dass vorberechnete Tabellen ("Rainbow-Tabellen") eine effektive Angriffsform darstellen.

Infolgedessen ist es nicht so konzipiert, dass es "geheim" ist oder dem Passwort in irgendeiner Weise Entropie hinzufügt, und deshalb wird es neben dem Hash des Passworts gespeichert. Tatsächlich ist es in den meisten Fällen kann nicht geheim sein, da die Anwendung selbst Zugriff auf das Salt benötigt, um den korrekten Hash des Passworts zu berechnen. Es ist sehr schwierig, den Zugriff auf die Anwendung zuzulassen, aber zu verhindern, dass ein Angreifer, der gegen die Anwendung verstoßen hat, dasselbe Privileg erhält.

Wie auch immer, um Ihre eigentliche Frage zu beantworten - in einer theoretischen Welt, in der Sie das Salz "knacken" mussten, weil es unbekannt war und aus irgendeinem Grund nicht abgerufen werden konnte, wäre es genau so komplex wie Passwörter. Grundsätzlich (Zeichenraum) ^ (Länge).

In Ihrem Beispiel geben Sie einen Hash von "H0mRpD2XJZDguAzxTehwzu" an. Angenommen, alphanumerische Groß-/Kleinschreibung entspricht einem Zeichenraum von 62 Zeichen und einer Länge von 22 Zeichen. Daher 62 ^ 22 = 3,397504e + 23 Jahre Vermutung unter der Annahme von 1 Milliarde Vermutungen pro Sekunde. Mit anderen Worten, nicht knackbar (dies setzt sogar voraus, dass das Passwort bekannt ist und Sie versuchen, einfach ein systemweites Salz zu erraten).

9
Peleus

Ein Salz wird neben dem Passwort gespeichert. Es gibt keine Regel, die besagt, dass es so sein muss, aber es ist ein logisches Ergebnis des beabsichtigten Zwecks eines Salzes. Das Erstellen eines Rainbow-Tisches ist keine triviale Aufgabe. Der springende Punkt ist, dass der Angreifer eine separate Rainbow-Tabelle für jedes gesalzene Passwort benötigen würde (in diesem Fall ist es einfacher, stattdessen jeden Passwort-Hash direkt anzugreifen).

Sie können eine lange Antwort auf Salz lesen, was klar machen sollte, warum es keinen Sinn macht, es geheim zu halten.

Wenn Sie etwas geheimes Salz einschließen möchten, sollten Sie nachlesen, was allgemein als Pfeffer bezeichnet wird, der adds ein anwendungsweiter geheimer Schlüssel in Ihre gesalzenen Passwörter. Dies könnte schützt Sie vor teilweisen Verstößen (wie Datenbankkompromissen beispielsweise durch SQL-Injection), hilft jedoch nicht bei vollständigen Systemverletzungen, es sei denn, Sie verwenden ein Hardware-Sicherheitsmodul (HSM) zum Schutz des Pfefferwertes.

4
Jacco

Wenn ein Angreifer nur den Hash und nicht das Salt kennt, muss er nicht nur jedes mögliche Passwort, sondern jedes mögliche Passwort mit jedem möglichen Salt testen. Bei langen und zufälligen Salzwerten ist dies praktisch unmöglich.

Dies ist jedoch kein realistisches Szenario. Wenn ein Angreifer ein System kompromittiert, müssen Sie davon ausgehen, dass er die Datenbank sowohl der Hashes als auch der Salze kompromittiert hat. Eine Trennung dieser beiden Datensätze ist nicht möglich, da sie immer zusammen verwendet werden.

3
Philipp