Wo lagern Sie Ihre Salzfäden?

Ich habe immer eine richtige Salt-Zeichenfolge pro Eintrag verwendet, wenn Kennwörter für die Datenbankspeicherung gehasht wurden. Für meine Bedürfnisse hat das Speichern des Salt in der Datenbank neben dem Hash-Passwort immer gut funktioniert.

Einige Leute empfehlen jedoch, das Salz getrennt von der Datenbank zu lagern. Ihr Argument ist, dass ein Angreifer, wenn die Datenbank kompromittiert ist, immer noch eine Regenbogentabelle erstellen kann, die eine bestimmte Salzkette berücksichtigt, um jeweils ein Konto zu knacken. Wenn dieses Konto über Administratorrechte verfügt, muss er möglicherweise nicht einmal andere knacken.

Lohnt es sich aus Sicherheitsgründen, Salze an einem anderen Ort zu lagern? Stellen Sie sich eine Webanwendung mit dem Servercode und der Datenbank auf demselben Computer vor. Wenn die Salze in einer flachen Datei auf diesem Computer gespeichert sind, besteht die Möglichkeit, dass bei einer Kompromittierung der Datenbank auch die Salzdatei gespeichert wird.

Gibt es dafür empfohlene Lösungen?

Der Punkt bei Regenbogentabellen ist, dass sie im Voraus erstellt und massenweise verteilt werden, um Rechenzeit für andere zu sparen. Das Generieren von Regenbogentabellen im laufenden Betrieb dauert genauso lange wie das direkte Knacken der Kombination aus Passwort und Salz (seitdem) Tatsächlich wird beim Generieren von Regenbogentabellen die Berechnungen für das brutale Erzwingen des Hash vorab ausgeführt. Daher ist das Argument, dass jemand "eine Regenbogentabelle generieren" könnte, wenn er das Salz kennt, falsch.

Es macht keinen Sinn, Salze in einer separaten Datei zu speichern, solange sie auf Benutzerbasis vorliegen. Der Sinn des Salzes besteht einfach darin, es so zu gestalten, dass eine Regenbogentabelle nicht jedes Kennwort in der Datenbank brechen kann.

Ich werde dies etwas anders betrachten.

Ich speichere immer das Salz, das mit dem gesalzenen Passwort-Hash gemischt ist.

Zum Beispiel werde ich die erste Hälfte des Salzes vor dem gesalzenen Hash des Passworts und die letzte Hälfte des Salzes nach dem gesalzenen Hash des Passworts platzieren. Die Anwendung kennt dieses Design, kann also diese Daten abrufen und den Salt- und Salted-Password-Hash abrufen.

Meine Begründung für diesen Ansatz:

Wenn die Passwort- / Hash-Daten kompromittiert sind und in die Hände eines Angreifers fallen, weiß der Angreifer nicht, was das Salz ist, wenn er sich die Daten ansieht. Auf diese Weise kann ein Angreifer praktisch keinen Brute-Force-Angriff ausführen, um ein Kennwort zu erhalten, das dem Hash entspricht, da er den Hash zunächst nicht kennt und nicht wissen kann, welche Teile der Daten Teile des Salt sind, oder Teile des Salted-Password-Hash (es sei denn, er kennt die Authentifizierungslogik Ihrer Anwendung ).

Wenn der gesalzene Passwort-Hash unverändert gespeichert wird, kann ein Brute-Force-Angriff ausgeführt werden, um ein Passwort zu erhalten, das beim Saltieren und Hashing dieselben Daten wie der gesalzene Passwort-Hash erzeugt.

Selbst wenn beispielsweise der gesalzene Passwort-Hash unverändert gespeichert, aber mit einem einzelnen zufälligen Byte vorangestellt wird, würde dies ebenfalls die Schwierigkeit erhöhen, solange der Angreifer nicht weiß, dass dieses erste Byte verworfen werden soll des Angriffs. Ihre Anwendung kann das erste Byte der Daten verwerfen, wenn sie zur Authentifizierung Ihres Benutzers verwendet wird.

Der Abschluss dazu ..

1) Speichern Sie niemals die Daten, die Ihre Authentifizierungsanwendung verwendet, in exakter Form.

2) Wenn möglich, halten Sie Ihre Authentifizierungslogik für zusätzliche Sicherheit geheim.

Gehen Sie noch einen Schritt weiter.

Wenn Sie die Authentifizierungslogik Ihrer Anwendung nicht geheim halten können, wissen viele Leute, wie Ihre Daten in der Datenbank gespeichert sind. Angenommen, Sie haben beschlossen, den gesalzenen Passwort-Hash zusammen mit dem Salz zu mischen, wobei ein Teil des Salzes dem gesalzenen Passwort-Hash vorangestellt ist und der Rest des Salzes ihn anhängt.

Bei der Generierung des zufälligen Salzes können Sie auch zufällig entscheiden, welchen Anteil Ihres Salzes Sie vor / nach dem gesalzenen Passwort-Hash speichern.

Beispielsweise generieren Sie ein zufälliges Salz von 512 Bytes. Sie hängen das Salt an Ihr Passwort an und erhalten den SHA-512-Hash Ihres Salted-Passworts. Sie generieren auch eine zufällige Ganzzahl 200. Anschließend speichern Sie die ersten 200 Bytes des Salzes, gefolgt vom gesalzenen Passwort-Hash, gefolgt vom Rest des Salzes.

Bei der Authentifizierung der Kennworteingabe eines Benutzers geht Ihre Anwendung über die Zeichenfolge und geht davon aus, dass das erste 1-Byte der Daten das erste 1-Byte des Salt ist, gefolgt vom Salted-Hash. Dieser Pass wird fehlschlagen. Die Anwendung wird fortgesetzt, indem die ersten 2 Bytes der Daten als die ersten 2 Bytes des Salzes verwendet werden, und wiederholt, bis ein positives Ergebnis gefunden wird, nachdem die ersten 200 Bytes als die ersten 200 Bytes des Salzes verwendet wurden. Wenn das Kennwort falsch ist, versucht die Anwendung weiterhin alle Permutationen, bis keine gefunden werden.

Die Vorteile dieses Ansatzes:

Erhöhte Sicherheit - selbst wenn Ihre Authentifizierungslogik bekannt ist, ist die genaue Logik zur Kompilierungszeit unbekannt. Es ist praktisch unmöglich, einen Brute-Force-Angriff durchzuführen, selbst wenn die genaue Logik bekannt ist. Erhöhte Salzlängen erhöhen die Sicherheit weiter.

Die Nachteile dieses Ansatzes:

Da die genaue Logik zur Laufzeit abgeleitet wird, ist dieser Ansatz sehr CPU-intensiv. Je länger das Salz ist, desto CPU-intensiver wird dieser Ansatz.

Die Authentifizierung falscher Passwörter ist mit den höchsten CPU-Kosten verbunden. Dies kann für legitime Anfragen kontraproduktiv sein, erhöht jedoch die Sicherheit gegen Angreifer.

Dieser Ansatz kann auf verschiedene Arten implementiert und durch Verwendung von Salzen mit variabler Breite und / oder gesalzenen Passwort-Hashes noch sicherer gemacht werden.

Oft werden sie dem Hash vorangestellt und im selben Feld gespeichert.

Sie müssen nicht separat gespeichert werden. Es geht darum, für jedes Kennwort ein zufälliges Salz zu verwenden, damit eine einzelne Regenbogentabelle nicht für Ihren gesamten Satz von Kennwort-Hashes verwendet werden kann. Bei zufälligen Salzen muss ein Angreifer jeden Hash einzeln brutal erzwingen (oder eine Regenbogentabelle für alle möglichen Salze berechnen - viel mehr Arbeit).

Wenn Sie einen sichereren Speicherort hätten, wäre es sinnvoll, nur die Hashes dort zu speichern.

Basierend auf der Entwicklung des ASP.NET MVC 4-Webanwendungsbuchs von William Penberthy:

1. Um Zugriff auf die in einer separaten Datenbank gespeicherten Salze zu erhalten, müssen Hacker zwei verschiedene Datenbanken hacken, um Zugriff auf das Salt und das gesalzene Passwort zu erhalten. Das Speichern in derselben Tabelle wie das Kennwort oder sogar in einer anderen Tabelle derselben Datenbank würde bedeuten, dass Hacker, wenn sie Zugriff auf die Datenbank erhalten, sowohl auf den Salt- als auch auf den Kennwort-Hash zugreifen können. Da Sicherheit den Prozess umfasst, das Hacken in das System zu teuer oder zeitaufwändig zu machen, um es wert zu sein, sollte eine Verdoppelung des Zugriffs, den ein Hacker erhalten müsste, das System sicherer machen.
2. Die Benutzerfreundlichkeit ist der Hauptgrund dafür, dass die Salze in derselben Datenbank wie die Hash-Passwörter gespeichert werden. Sie müssten nicht sicherstellen, dass zwei Datenbanken immer gleichzeitig und immer synchron verfügbar sind. Der Vorteil eines Salt ist minimal, wenn jeder Benutzer ein zufälliges Salt hat, denn obwohl dies das Auffinden des Kennworts einer Person erleichtern könnte, ist der Kraftaufwand zum Knacken der Kennwörter des Systems insgesamt hoch. In dieser Diskussionsebene ist das wirklich die Erwartung: die Passwörter zu schützen. Wenn die Hacker eine Kopie der Datenbank erworben haben, sind Ihre Anwendungsdaten bereits gefährdet. An diesem Punkt besteht das Problem darin, die Risiken der Benutzer aufgrund des Potenzials gemeinsamer Kennwörter zu verringern.
3. Die Anforderung, zwei separate verknüpfte Datenbanken zu verwalten, ist umfangreich. Zugegeben, es fügt die Wahrnehmung von Sicherheit hinzu, aber der einzige Vorteil, den es bietet, ist, dass es ein Passwort schützt, ein einzelnes Datenelement. Wenn jedes Feld in der Datenbank einzeln verschlüsselt wäre und dasselbe Salz dafür verwendet würde, wäre es sinnvoller, es getrennt von den Daten zu speichern, da die grundlegende Sicherheit Ihres Systems verbessert wird.

Der Sinn eines Salzes besteht darin, alle Regenbogentabellen unbrauchbar zu machen und einen neuen Satz davon zu erstellen. Das Erraten einer Schnur dauert genauso lange wie das Erstellen eines Regenbogentisches. Zum Beispiel ist der SHA-256-Hash von "Passwort" 5e88 4898 da28 0471 51d0 e56f 8dc6 2927 7360 3d0d 6aab bdd6 2a11 ef72 1d15 42d8. Nachdem ein Salt hinzugefügt wurde, z. B. "badpassword", lautet die neue zu hashende Zeichenfolge "passwordbadpassword", wodurch sich die Ausgabe aufgrund des Lawineneffekts dramatisch ändert 457b f8b5 37f1 802e f9c8 2e46 b8d3 f8b5 721b 7cbb d485 f0bb e523 bfbe 73e6 58d6.

Normalerweise wird das Salt nur in derselben Datenbank wie das Passwort gespeichert, auch weil es wahrscheinlich ist, dass die andere Datenbank gehackt wird, wenn eine Datenbank gehackt wird.