it-swarm.com.de

Was ist die optimale Länge für das Benutzerkennwort salt?

Jedes salt hilft offensichtlich beim Salting und Hashing des Passworts eines Benutzers. Gibt es bewährte Methoden für die Dauer des Salzes? Ich werde das Salz in meiner Benutzertabelle speichern, also möchte ich den besten Kompromiss zwischen Speichergröße und Sicherheit. Ist eine zufällige 10 Zeichen Salz genug? Oder brauche ich etwas länger?

124
David

Die meisten dieser Antworten sind etwas falsch und zeigen eine Verwechslung zwischen Salt- und Kryptografieschlüsseln. Der Zweck des Einschlusses von Salzen besteht darin, die zum Hashing des Kennworts jedes Benutzers verwendete Funktion so zu ändern, dass jeder gespeicherte Kennwort-Hash einzeln angegriffen werden muss. Die einzige Sicherheitsanforderung besteht darin, dass sie für jeden 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 auch bei einer Milliarde registrierter Benutzer wiederholen. 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 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 des Salzgehalts über 64 Bit sind nicht hoch, es gibt jedoch keinen Sicherheitsgrund dafür.

Es ist ein gewisser Vorteil, zusätzlich zum Benutzer-Salt auch ein standortweites Salt zu verwenden. Dies verhindert mögliche Kollisionen mit an anderen Standorten gespeicherten Kennwort-Hashes und die Verwendung von Allzweck-Rainbow-Tabellen, obwohl sogar 32 Bit Salz ist genug, um Rainbow-Tische zu einem unpraktischen Angriff zu machen.

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

65
SecurityJoe

Derzeit akzeptierte Standards für Hashing-Passwörter erstellen Sie für jedes Passwort ein neues 16-stelliges Salt und speichern Sie das Salt mit dem Passwort-Hash.

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

34
David Schmitt

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 Werkzeuge auf einer zu niedrigen Ebene.

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

Mehr als 256 Bit bedeuten mathematisch keine Verbesserung der Sicherheit. Wenn Sie sich für ein kürzeres Salz entscheiden, kann dies jedoch dazu führen, dass ein Rainbow-Tisch Ihre Salzlänge erreicht - insbesondere bei kürzeren Salzen.

24
Stephen Touset

Wikipedia :

Die in Linux, BSD Unixes und Solaris verwendeten Methoden SHA2-crypt und bcrypt haben 128-Bit-Salze. Diese höheren Salt-Werte machen auf absehbare Zeit Vorberechnungsangriffe auf diese Systeme für nahezu jede Länge von Passwörtern unmöglich.

128-Bit-Salt (16-Byte-Salt) ist ausreichend. Sie können es als eine Folge von 128 / 4 = 32 hexadezimale Ziffern.

7

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

Z.B. Wenn Sie SHA-512 verwenden, verwenden Sie 256-Bit-Salt, da die von SHA-512 bereitgestellte Sicherheit 256-Bit beträgt.

2