Was ist die optimale Länge für das Benutzerkennwort Salt? [geschlossen]

Jegliches Salz hilft natürlich beim Salzen und Hashing des Passworts eines Benutzers. Gibt es Best Practices für die Dauer des Salzes? Ich werde das Salz in meiner Benutzertabelle speichern, daher möchte ich den besten Kompromiss zwischen Speichergröße und Sicherheit. Ist ein zufälliges Salz mit 10 Zeichen genug? Oder brauche ich etwas länger?

Die meisten dieser Antworten sind etwas falsch und zeigen eine Verwechslung zwischen Salzen und kryptografischen Schlüsseln. Der Zweck des Einfügens von Salzen besteht darin, die Funktion zum Hashing des Kennworts jedes Benutzers so zu ändern, dass jeder gespeicherte Kennwort-Hash einzeln angegriffen werden muss. Die einzige Sicherheitsanforderung besteht darin, dass sie pro Benutzer eindeutig sind. Es hat keinen Vorteil, dass sie unvorhersehbar oder schwer zu erraten sind.

Salze müssen nur lang genug sein, damit das Salz jedes Benutzers einzigartig ist. Es ist sehr unwahrscheinlich, dass sich zufällige 64-Bit-Salze jemals wiederholen, selbst bei einer Milliarde registrierter Benutzer. Dies sollte also in Ordnung sein. Ein einzeln wiederholtes Salt ist ein relativ geringes Sicherheitsrisiko. Es ermöglicht einem Angreifer, zwei Konten gleichzeitig zu durchsuchen, beschleunigt jedoch insgesamt die Suche in der gesamten Datenbank nicht wesentlich. Selbst 32-Bit-Salze sind für die meisten Zwecke akzeptabel. Im schlimmsten Fall wird die Suche eines Angreifers um etwa 58% beschleunigt. Die Kosten für die Erhöhung der Salze über 64 Bit hinaus sind nicht hoch, aber es gibt keinen Sicherheitsgrund dafür.

Die Verwendung eines standortweiten Salt zusätzlich zum Salz pro Benutzer bietet einige Vorteile. Dies verhindert mögliche Kollisionen mit an anderen Standorten gespeicherten Passwort-Hashes und verhindert die Verwendung von Regenbogen-Allzwecktabellen, obwohl sogar 32 Bit Salz reicht aus, um Regenbogentische zu einem unpraktischen Angriff zu machen.

Noch einfacher - und Entwickler übersehen dies immer -, wenn Sie eindeutige Benutzer-IDs oder Anmeldenamen haben, dienen diese als Salz. Wenn Sie dies tun, sollten Sie ein Site-weites Salt hinzufügen, um sicherzustellen, dass Sie sich nicht mit Benutzern eines anderen Systems überschneiden, die dieselbe gute Idee hatten.

Derzeit akzeptierte Standards für das Hashing von Passwörtern erstellen für jedes Passwort ein neues 16 Zeichen langes Salt und speichern das Salt mit dem Passwort-Hash.

Natürlich sollte die richtige kryptografische Sorgfalt angewendet werden, um wirklich zufälliges Salz zu erzeugen.

Bearbeiten: Meine unten stehende Antwort beantwortet die gestellte Frage, aber die "echte" Antwort lautet: Verwenden Sie einfach bcrypt , scrypt oder Argon2 . Wenn Sie Fragen wie diese stellen, verwenden Sie mit ziemlicher Sicherheit Tools auf einer zu niedrigen Ebene.

Ehrlich gesagt gibt es keinen vertretbaren Grund dafür, dass das Salz nicht genau so lang ist wie das Hash-Passwort. Wenn Sie SHA-256 verwenden, haben Sie einen 256-Bit-Hash. Es gibt keinen Grund, kein 256-Bit-Salz zu verwenden.

Mehr als 256 Bit bringen Ihnen mathematisch keine Verbesserung der Sicherheit. Wenn Sie jedoch ein kürzeres Salz verwenden, kann dies immer dazu führen, dass ein Regenbogentisch Ihre Salzlänge einholt - insbesondere bei kürzeren Salzen.

Wikipedia :

Die in Linux, BSD Unixes und Solaris verwendeten Methoden SHA2-crypt und bcrypt haben Salze von 128 Bit. Diese größeren Salzwerte machen Vorberechnungsangriffe für nahezu jede Kennwortlänge auf absehbare Zeit gegen diese Systeme unmöglich.

128-Bit-Salz (16 Byte) reicht aus. Sie können es als Folge von 128 / 4 = 32hexadezimalen Ziffern darstellen.

Eine Antwort könnte darin bestehen, den Wert, den der zu verwendende Hash für die Sicherheit bietet, als Salzgröße zu verwenden.

Wenn Sie beispielsweise SHA-512 verwenden möchten, verwenden Sie 256-Bit-Salt, da die von SHA-512 bereitgestellte Sicherheit 256-Bit beträgt.