Wie Mike und Gumbo in Kommentaren erwähnt haben, soll ein Salt schlechte Passwörter nicht schützen. Es soll die Angreifer davon abhalten, die gesamte Datenbank auf einmal zu beschädigen. Die Länge des Salzes soll das Brechen der gespeicherten Passwörter nicht erschweren. Es soll sicherstellen, dass Ihr Salz im Vergleich zu anderen im Internet einigermaßen einzigartig ist und (wenn Sie es richtig machen) keine zwei Ihrer Benutzer das gleiche Salz haben.

Stellen Sie sich vor, Sie haben 20 Benutzer die alle "Gott" als Passwort haben. Stellen Sie sich die folgenden Szenarien vor:

1. Kennwörter sind ungesalzen
   Der Angreifer kann eine vorberechnete Tabelle verwenden, um das Kennwort eines Benutzers in sehr zu brechen em> kurze Bestellung. Darüber hinaus hat er, sobald er die erste der 20 hat, auch die anderen 19, da ihre Hashes identisch wären.

2. Passwörter sind gesalzen. Das verwendete Salz ist ziemlich kurz. Für alle Benutzer wird das gleiche Salz verwendet.
   Der Angreifer muss möglicherweise etwas suchen, stößt jedoch möglicherweise auf eine vorberechnete Tabelle, die speziell für Ihre Konfiguration erstellt wurde. Nach diesem Punkt siehe Szenario 1.

3. Kennwörter sind gesalzen. Das verwendete Salz ist ziemlich stark. Für alle Benutzer wird das gleiche Salz verwendet.
   Möglicherweise findet der Angreifer im Internet keine vorberechnete Tabelle für Ihr System. Er muss einen eigenen machen. Dies dauert etwas länger. Danach kehren wir jedoch wieder zu Szenario 1 zurück.

4. Passwörter sind gesalzen. Das verwendete Salz ist ziemlich stark. Jeder Benutzer hat ein einzigartiges Salz.
   Dies ist, was Sie tun sollten . Der Angreifer kann nicht nur keine vorberechnete Tabelle für Ihr System finden, es lohnt sich auch nicht, seine eigene zu erstellen. Jede Vorverarbeitung, die er möglicherweise durchführt, funktioniert nur gegen einen Benutzer. Selbst wenn er einen der 20 zuvor genannten Benutzer trifft, kennt er die anderen 19 nicht, da die Hashes alle unterschiedlich sind. Jedes Passwort muss daher einzeln angegriffen werden, und das wird eine Weile dauern, wenn Sie auch einen starken und langsamen Hashing-Algorithmus verwenden, wie Sie es sollten. Die Chancen stehen gut, dass die schwachen Passwörter letztendlich immer noch kompromittiert werden. Der Angreifer braucht nur ein gutes Stück mehr Zeit, um alle zu überwinden, und Sie werden nicht feststellen, dass Teile Ihrer Benutzer sofort kompromittiert werden, nur weil sie dasselbe Kennwort haben.
ol>

Verwenden Sie also lange Salze und machen Sie sie für jeden Benutzer einzigartig. Aber rechnen Sie nicht damit, um einzelnen Benutzern viel zu helfen, wenn sie "Gott" als Passwort verwenden.

Ein zu langes Salz verringert die Sicherheit nicht. Ein zu kurzes Salz verringert die Sicherheit.

Wenn das Salz länger wird, verbessert sich die Sicherheit. Irgendwann werden Sie eine Grenze überschreiten, wo Sie mit zunehmender Salzlänge abnehmende Renditen erzielen. Und irgendwann werden Sie eine andere Grenze überschreiten, an der ein längeres Salz keinerlei Sicherheit bietet.

Da ein längeres Salz jedoch keine nennenswerten Kosten verursacht, gibt es kaum einen Grund, die Verlängerung bis zu Ihnen zu beenden die zweite Grenze erreichen. Selbst wenn Sie die Salzlänge darüber hinaus erhöhen, besteht der einzige Nachteil in geringen zusätzlichen Kosten in Bezug auf Lager- und Verarbeitungszeit.

Leider werden Salze häufiger mit einer Länge unterhalb des unteren der beiden Schwellenwerte erzeugt

Was sind also die beiden Schwellenwerte?

Der untere Schwellenwert wird durch die Anzahl der Benutzer und den Zweck des Salt bestimmt, der für jedes jemals gewählte Passwort unterschiedlich sein soll jeder Benutzer. Wenn wir einige konservative Schätzungen vornehmen, beträgt die Anzahl der Benutzer weltweit weniger als 10 ^ 10, und jeder Benutzer hat Kennwörter für weniger als 10 ^ 2 Systeme, und im Laufe seiner Lebensdauer ändert sich dieses Kennwort weniger als 10 ^ 3 Mal. Das bedeutet, dass es insgesamt weniger als 10 ^ 15 Passwörter gibt. In Anbetracht dessen könnte man fälschlicherweise den Schluss ziehen, dass 50 Bit Entropie im Salz ausreichen, um zu gewährleisten, dass sich niemals zwei Salze wiederholen, aber aufgrund des Geburtstagsparadoxons müssen wir diese Zahl verdoppeln.

Also einmal Das Salz wächst länger als 100 Bit. Wir sehen abnehmende Renditen in Bezug auf zusätzliche Sicherheit. Die 100-Bit-Schwelle war mit viel Raten verbunden. Die nächste Schwelle beinhaltet viel weniger Raten. Mehr als 100 Bit Entropie im Salz verbessern die Sicherheit immer noch, nur nicht wesentlich.

Sobald das Salz länger als die Ausgabe der zugrunde liegenden Hash-Funktion wird, gibt es jedoch keine zusätzliche Sicherheit, wenn es hergestellt wird länger. Was der Schwellenwert ist, hängt von der Hash-Funktion ab. Diese reichen von 128 bis 512 Bit für typische Hashes.

Denken Sie daran, dass Salze normalerweise mit 6 Bit Entropie pro Zeichen erzeugt werden. Sie benötigen also 86 Zeichen Salz, um die 512 Bit Entropie zu erreichen.

Die einzige Eigenschaft eines Salzes, die aus Sicherheitsgründen wichtig ist, ist, dass es global eindeutig ist. Die Länge kann sich darauf auswirken, wie einzigartig das Salz sein kann, ist jedoch aus jeder anderen Perspektive irrelevant. Unter der Annahme, dass es sich positiv oder negativ auf irgendetwas auswirkt, muss das Salz gebeten werden, eine Funktion auszuführen, die es niemals erfüllen sollte.

Ein Salz sollte also lang genug sein, um die Einzigartigkeit angemessen sicherzustellen, und das auch ist Alles. Vorausgesetzt, Ihr Salz hat eine gute Einzigartigkeit, wirkt sich dies nicht mehr positiv oder negativ auf die Sicherheit aus, sondern verschwendet mit Sicherheit Speicherplatz.

Andere haben sich zur richtigen Verwendung von Salzen und Passwörtern geäußert, aber vielleicht ist es nützlich, ein Wort zu Hash-Funktionen hinzuzufügen, da Ihre Frage auf eine etwas falsche Intuition ihrer Funktionsweise hindeutet.

Von Natur aus Eine gute kryptografische Hash-Funktion sollte Sie nicht erraten lassen, wie ähnlich die Eingaben basierend auf den Hash-Werten selbst waren. Andernfalls könnte es umgekehrt werden, indem dieser Abstand schrittweise verringert wird, was viel weniger kostspielig wäre als das reine Brute-Force-Raten. Daher sollte Hash (salt1 + "12345") Hash (salt1 + "67890") oder Hash ("12345") nicht ähnlicher sein als Hash (salt2 + "67890").

The Der springende Punkt ist, sicherzustellen, dass die Eingaben (und damit der Hash) nicht identisch sind, auch wenn zwei Konten zufällig dasselbe Kennwort verwenden, Ähnlichkeit jedoch keine sein sollte Problem.

Die Länge eines Salzes folgt dem Gesetz der Verringerung der Rendite.

Sie "knacken" niemals ein Salz - was Sie knacken, ist das Hash-Passwort, für das das Salz wird angehängt. Das Salz adressiert nur die Bedrohung durch Regenbogentabellen - die Möglichkeit, vorberechnete Haschentabellen zu finden, sodass Sie den mühsamen Prozess des Brute-Forcing überspringen können.

Zu diesem Zweck benötigen Sie lediglich lange genug Salze dass noch niemand umfassende Regenbogentabellen für all diese möglichen Salze erstellt hat. Und aufgrund der Kosten für die Erstellung einer Regenbogentabelle und des exponentiellen Anstiegs der Anzahl der Salze, die Sie berechnen müssen, wenn Sie die maximale Salzlänge erhöhen, ist dies keine sehr schwierige Anforderung: Nur wenige Zeichen Salz sind bereits vorhanden Es ist sehr wahrscheinlich, dass niemand umfassende Regenbogentabellen für Salze Ihres Formats berechnet hat.

Um aus dem Nichts einen zufälligen Wert auszuwählen, sind Salze mit beispielsweise 16 Hex-Zeichen oder mehr recht gut. Angenommen, Ihre Methode zur zufälligen Auswahl weist keine ausnutzbaren Mängel auf.

Darüber hinaus wird die Erhöhung der Sicherheit immer vernachlässigbarer.