it-swarm.com.de

Ihr Passwort salzen: Best Practices?

Ich war schon immer neugierig ... Was ist besser, wenn ich ein Passwort für das Hashing salze: Präfix oder Postfix? Warum? Oder spielt es eine Rolle, solange Sie salzen?

Um zu erklären: Wir alle wissen (hoffentlich) jetzt, dass wir ein Passwort salzen müssen , bevor wir es für die Speicherung in der Datenbank haben [ Bearbeiten: So können Sie Dinge wie vermeiden, die Jeff Atwood kürzlich passiert sind ]. In der Regel wird dazu das Salt mit dem Kennwort verknüpft, bevor es den Hashing-Algorithmus durchläuft. Aber die Beispiele variieren ... Einige Beispiele stellen das Salt vor das Passwort. Einige Beispiele fügen das Salt after das Passwort hinzu. Ich habe sogar einige gesehen, die versucht haben, das Salz in die Mitte zu legen.

Welches ist die bessere Methode und warum? Gibt es eine Methode, die die Wahrscheinlichkeit einer Hash-Kollision verringert? Mein Googeln hat keine anständige Analyse zu diesem Thema ergeben.

Edit: Tolle Antworten Leute! Es tut mir leid, dass ich nur eine Antwort auswählen konnte. :)

155
Randolpho

Präfix oder Suffix sind irrelevant, es geht nur darum, dem Kennwort etwas Entropie und Länge hinzuzufügen.

Sie sollten diese drei Dinge berücksichtigen:

  1. Das Salz muss für jedes gespeicherte Passwort unterschiedlich sein. (Dies ist ein weit verbreitetes Missverständnis.)
  2. Verwenden Sie einen kryptografisch sicheren Zufallszahlengenerator.
  3. Wählen Sie ein ausreichend langes Salz. Denken Sie an das Geburtstagsproblem.

Es gibt ein exzellentes Antwort von Dave Sherohman auf eine andere Frage, warum Sie zufällig erzeugte Salze anstelle des Namens eines Benutzers (oder anderer persönlicher Daten) verwenden sollten. Wenn Sie diesen Vorschlägen folgen, spielt es keine Rolle, wo Sie Ihr Salz hineingeben.

105
Georg Schölly

Ich denke, es ist alles Semantik. Das Setzen davor oder danach spielt keine Rolle, es sei denn, es handelt sich um ein ganz bestimmtes Bedrohungsmodell.

Die Tatsache, dass es dort ist, soll Rainbow-Tische besiegen.

Das Bedrohungsmodell, auf das ich anspielte, wäre das Szenario, in dem der Gegner kann Rainbow-Tabellen mit gebräuchlichen Salzen an das Kennwort anhängen/diesem voranstellen lässt. (Sagen Sie die NSA) Sie vermuten, sie haben es entweder angehängt oder vorangestellt, aber nicht beide. Das ist albern, und es ist eine schlechte Vermutung.

Es ist besser anzunehmen, dass sie die Kapazität haben, diese Rainbow-Tabellen zu speichern, aber nicht etwa Tabellen mit seltsamen Salzen, die sich in der Mitte des Passworts befinden. In dass engen Fällen würde ich vermuten, dass eingestreut am besten wäre.

Wie ich sagte. Das ist Semantik. Wählen Sie ein anderes Salt pro Passwort, ein langes Salt und fügen Sie darin ungerade Zeichen wie Symbole und ASCII Codes ein: © ¤¡

25
Tom Ritter

Die wirkliche Antwort, die niemand angerührt zu haben scheint, lautet: beide sind falsch . Wenn Sie Ihre eigene Krypto implementieren, werden Sie Fehler machen , unabhängig davon, wie trivial ein Teil ist, von dem Sie denken, dass Sie dies tun.

HMAC ist ein besserer Ansatz, aber selbst dann, wenn Sie etwas wie SHA-1 verwenden, haben Sie bereits einen Algorithmus ausgewählt, der für Passwort-Hashing ungeeignet ist aufgrund seines Designs für Geschwindigkeit. Verwenden Sie etwas wie bcrypt oder möglicherweise scrypt und nehmen Sie das Problem ganz aus den Händen.

Oh, und denken Sie nicht einmal daran, die resultierenden Hashes auf Gleichheit mit Ihren Dienstprogrammen für den Vergleich von Programmiersprachen oder Datenbankzeichenfolgen zu vergleichen. Diese vergleichen Zeichen für Zeichen und schließen als false kurz, wenn sich ein Zeichen unterscheidet. Jetzt können Angreifer statistische Methoden verwenden, um herauszufinden, was der Hash ist, ein Charakter nach dem anderen.

18
Stephen Touset

Es sollte keinen Unterschied machen. Der Hasch wird nicht mehr leicht zu erraten sein, wo immer Sie das Salz setzen. Hash-Kollisionen sind selten und unvorhersehbar, da sie absichtlich nicht linear sind. Wenn sich dies auf die Sicherheit auswirken würde, würde dies auf ein Problem mit dem Hashing hinweisen, nicht auf das Einsalzen.

9
Phil H

Wenn Sie einen kryptografisch sicheren Hash verwenden, sollte es keine Rolle spielen, ob Sie ein Pre- oder Postfix durchführen. Ein Punkt des Hashing ist, dass eine einzelne Bitänderung in den Quelldaten (egal wo) einen anderen Hash erzeugen sollte.

Was ist Wichtig ist jedoch, lange Salze zu verwenden, diese mit einem geeigneten kryptografischen PRNG zu generieren und Salze pro Benutzer zu haben. Speichern der benutzerspezifischen Salze in Ihrer Datenbank ist nicht ein Sicherheitsproblem mit einem Site-weiten Hash ist.

7
snemarch

Zunächst wird der Begriff "Rainbow table" konsequent missbraucht. Eine "Rainbow" -Tabelle ist nur eine bestimmte Art der Nachschlagetabelle, die eine bestimmte Art der Datenkomprimierung auf den Schlüsseln ermöglicht. Durch Tauschen der Berechnung gegen Speicherplatz kann eine Nachschlagetabelle, die 1000 TB) benötigt, tausendmal komprimiert werden, damit sie auf einem kleineren Laufwerk gespeichert werden kann.

Sie sollten sich Gedanken über Hash-Passwörter für Lookup-Tabellen, Rainbow oder andere Dinge machen.

@ onebyone.livejournal.com:

Der Angreifer hat 'Rainbow-Tabellen', die nicht aus den Hashes der Wörterbuchwörter bestehen, sondern aus dem Status der Hash-Berechnung, kurz bevor die Hash-Berechnung abgeschlossen wird.

In diesem Fall ist es möglicherweise billiger, einen Kennwortdateieintrag mit Postfix Salt als mit dem Präfix Salt zu erzwingen: Für jedes Wörterbuch-Word wird der Status geladen, die Salt-Bytes werden in den Hash eingefügt und anschließend abgeschlossen. Mit dem Präfix salt hätten die Berechnungen für jedes Wörterbuchwort nichts gemeinsam.

Für eine einfache Hash-Funktion, die die Eingabezeichenfolge linear durchsucht, wie z. B. einen einfachen linearen Kongruenzgenerator, ist dies ein praktischer Angriff. Eine kryptografisch sichere Hash-Funktion ist jedoch bewusst so konzipiert, dass sie mehrere Runden umfasst, von denen jede alle Bits der Eingabezeichenfolge verwendet, sodass die Berechnung des internen Zustands nmittelbar vor zum Hinzufügen des Salt nicht sinnvoll ist nach der ersten runde. Zum Beispiel hat SHA-1 80 Runden.

Darüber hinaus setzen Passwort-Hashing-Algorithmen wie PBKDF ihre Hash-Funktion mehrmals zusammen (es wird empfohlen, PBKDF-2 mindestens 1000 Mal zu iterieren, wobei jede Iteration SHA-1 zweimal anwendet), was diesen Angriff doppelt unpraktisch macht.

5
cygil

BCrypt Hash wenn die Plattform einen Provider hat. Ich finde es toll, dass Sie sich keine Sorgen um die Herstellung der Salze machen und sie sogar noch stärker machen können, wenn Sie möchten.

4
Samuel

Das Einfügen einer beliebigen Anzahl von Zeichen in das Passwort ist der am wenigsten erwartete und daher sozial "sicherste" Fall, aber im Allgemeinen ist es nicht sehr wichtig, solange Sie ein langes, eindeutiges Passwort verwenden Saiten für Salze.

2
jeffcook2150