Jede Salz ist natürlich hilfreich, wenn das Passwort eines Benutzers gesalzen und gehasht wird. Gibt es Best Practices dafür, wie lang das Salt sein sollte? Ich werde das Salt in meiner Benutzertabelle speichern, daher möchte ich den besten Kompromiss zwischen Speichergröße und Sicherheit finden. Ist ein zufälliges 10-Zeichen-Salz ausreichend? Oder brauche ich etwas Längeres?
Antworten
Zu viele Anzeigen?
SecurityJoe
Punkte
1085
Die meisten dieser Antworten sind ein wenig fehlgeleitet und zeigen eine Verwechslung zwischen Salts und kryptografischen Schlüsseln. Der Zweck der Einbeziehung von Salts besteht darin, die Funktion, die zum Hashing der Passwörter der einzelnen Benutzer verwendet wird, so zu ändern, dass jeder gespeicherte Passwort-Hash einzeln angegriffen werden muss. Die einzige Sicherheitsanforderung besteht darin, dass sie für jeden Benutzer eindeutig sind; es bringt keinen Vorteil, wenn sie unvorhersehbar oder schwer zu erraten sind.
Die Salts müssen nur lang genug sein, damit das Salz jedes Nutzers eindeutig ist. Es ist sehr unwahrscheinlich, dass sich zufällige 64-Bit-Salts wiederholen, selbst bei einer Milliarde registrierter Benutzer, so dass dies kein Problem darstellen sollte. Ein einmalig wiederholtes Salt ist ein relativ geringes Sicherheitsproblem, da es einem Angreifer die Möglichkeit gibt, zwei Konten gleichzeitig zu durchsuchen, aber insgesamt wird die Suche in der gesamten Datenbank nicht wesentlich beschleunigt. Selbst 32-Bit-Salts sind für die meisten Zwecke akzeptabel, da sie im schlimmsten Fall die Suche eines Angreifers um etwa 58 % beschleunigen. Die Kosten für die Erhöhung der Salts über 64 Bit hinaus sind nicht hoch, aber es gibt keinen Grund, dies aus Sicherheitsgründen zu tun.
Es ist von gewissem Vorteil, zusätzlich zum benutzerspezifischen Salt ein standortweites Salt zu verwenden. Dies verhindert mögliche Kollisionen mit Passwort-Hashes, die an anderen Standorten gespeichert sind, und verhindert die Verwendung von Regenbogentabellen für allgemeine Zwecke, obwohl selbst 32 Bit Salt ausreichen, um Regenbogentabellen zu einem unbrauchbaren Angriff zu machen.
Noch einfacher - und das wird von den Entwicklern immer übersehen - ist es, wenn Sie eindeutige Benutzerkennungen oder Anmeldenamen haben, die sich hervorragend als Salz eignen. Wenn Sie dies tun, sollten Sie einen standortweiten Salt hinzufügen, um sicherzustellen, dass Sie sich nicht mit Benutzern eines anderen Systems überschneiden, die dieselbe glänzende Idee hatten.
David Schmitt
Punkte
56455
Derzeit anerkannte Normen zum Hashing von Kennwörtern für jedes Kennwort ein neues, 16 Zeichen langes Salt erstellen und das Salt mit dem Kennwort-Hash speichern.
Natürlich sollte bei der Verschlüsselung darauf geachtet werden, dass wirklich zufälliges Salz verwendet wird.
Stephen Touset
Punkte
2504
Edit: Meine unten stehende Antwort beantwortet die Frage, wie sie gestellt wurde, aber die "echte" Antwort ist: Verwenden Sie einfach bcrypt , scrypt ou Argon2 . Wenn Sie solche Fragen stellen, verwenden Sie höchstwahrscheinlich Werkzeuge auf einem zu niedrigen Niveau.
Ehrlich gesagt gibt es keinen vertretbaren Grund, warum der Salt nicht genau so lang sein sollte wie das gehashte Kennwort. Wenn Sie SHA-256 verwenden, dann haben Sie einen 256-Bit-Hash. Es gibt keinen Grund, nicht ein 256-Bit-Salz zu verwenden.
Mehr als 256 Bits bringen Ihnen mathematisch gesehen keine Verbesserung der Sicherheit. Wenn Sie jedoch ein kürzeres Salz verwenden, kann es immer zu einer Situation kommen, in der eine Regenbogentabelle Ihre Salzlänge einholt - insbesondere bei kürzeren Salts.
tellnobody1
Punkte
8331
Die SHA2-crypt- und bcrypt-Methoden, die in Linux, BSD-Unixen und Solaris verwendet werden, haben Salts von 128 Bit. Diese größeren Salt-Werte machen Vorberechnungsangriffe für fast jede Passwortlänge undurchführbar gegen diese Systeme auf absehbare Zeit unmöglich.
128-Bit-Salz (16 Byte) reicht aus. Sie können es als eine Folge von 128 / 4 = 32 hexadezimale Ziffern.
Roberto Martelloni
Punkte
557
