it-swarm.com.de

Wo lagerst du deine Salzschnüre?

Ich habe immer eine korrekte Salt-Zeichenfolge pro Eintrag verwendet, wenn ich Kennwörter für die Datenbankspeicherung hashe. Für meine Bedürfnisse hat das Speichern des Salzes in der DB neben dem gehashten Passwort immer gut funktioniert.

Einige Leute empfehlen jedoch, das Salz getrennt von der Datenbank zu lagern. Sie argumentieren, dass ein Angreifer bei einer Kompromittierung der Datenbank immer noch eine Rainbow-Tabelle erstellen kann, die eine bestimmte Salt-Zeichenfolge berücksichtigt, um jeweils ein Konto zu knacken. Wenn dieses Konto über Administratorrechte verfügt, muss es möglicherweise nicht einmal andere knacken.

Lohnt es sich aus Sicherheitsgründen, Salze an einem anderen Ort aufzubewahren? Stellen Sie sich eine Webanwendung mit dem Servercode und der Datenbank auf demselben Computer vor. Wenn die Salze in einer Einfachdatei auf diesem Computer gespeichert sind, ist die Wahrscheinlichkeit groß, dass bei einer Kompromittierung der Datenbank auch die Salzdatei vorhanden ist.

Gibt es dafür empfohlene Lösungen?

241
friedo

Der Vorteil von Rainbow - Tabellen besteht darin, dass sie im Voraus erstellt und in großen Mengen verteilt werden, um Rechenzeit für andere zu sparen. Das Generieren von Rainbow - Tabellen im laufenden Betrieb dauert genauso lange wie das direkte Knacken der Kombination aus Kennwort und Salt (seit Effektiv läuft das, was beim Generieren von Rainbow-Tabellen getan wird, vor der Berechnung ab, um den Hash zu erzwingen. Daher ist das Argument, dass jemand, der das Salz kennt, "eine Rainbow-Tabelle generieren" könnte, falsch.

Es hat keinen wirklichen 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 Rainbow-Tabelle nicht jedes Kennwort in der DB auflösen kann.

246
Amber

Ich werde dies etwas anders interpretieren.

Ich bewahre das Salz immer gemischt mit dem Salted-Password-Hash auf.

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 ist sich dieses Entwurfs bewusst, sodass sie diese Daten abrufen und den Salt- und Salted-Password-Hash abrufen kann.

Meine Begründung für diesen Ansatz:

Wenn die Passwort-/Hash-Daten kompromittiert werden und einem Angreifer in die Hände fallen, weiß der Angreifer nicht, was das Salz von der Betrachtung der Daten ist. Auf diese Weise kann ein Angreifer praktisch keinen Brute-Force-Angriff durchführen, um ein Kennwort zu erhalten, das dem Hash entspricht, da er den Hash zunächst nicht kennt und nicht weiß, welche Teile der Daten Teile des Salt sind, oder Teile des Salted-Password-Hashs (), 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 im gesalzenen und gehashten Zustand dieselben Daten wie der gesalzene Passwort-Hash erzeugt.

Selbst wenn beispielsweise der Hash mit gesalzenem Kennwort unverändert gespeichert wurde, jedoch ein einzelnes Zufallsbyte vorausgesetzt wird, würde dies die Schwierigkeit ebenfalls erhöhen, solange der Angreifer nicht weiß, dass dieses erste Byte verworfen werden soll des Angriffs. Ihre Anwendung würde wissen, dass das erste Byte der Daten verworfen werden muss, wenn es zur Authentifizierung Ihres Benutzers verwendet wird.

Die Schlussfolgerung dazu ..

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

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

Geh noch einen Schritt weiter ..

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

Beim Generieren des Zufallssalzes können Sie auch nach dem Zufallsprinzip entscheiden, welchen Anteil Ihres Salzes Sie vor/nach dem Salted-Password-Hash speichern möchten.

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

Wenn Sie die Kennworteingabe eines Benutzers authentifizieren, wird Ihre Anwendung die Zeichenfolge übergehen und davon ausgehen, 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 wird wiederholt, bis ein positives Ergebnis gefunden wird, nachdem die ersten 200 Bytes als die ersten 200 Bytes des Salzes verwendet wurden. Wenn das Passwort falsch ist, versucht die Anwendung weiterhin alle Permutationen, bis keine mehr gefunden werden.

Die Vorteile dieses Ansatzes:

Erhöhte Sicherheit - selbst wenn Ihre Authentifizierungslogik bekannt ist, ist die genaue Logik zum Zeitpunkt der Kompilierung nicht bekannt. Es ist praktisch unmöglich, einen Brute-Force-Angriff durchzuführen, selbst wenn man die genaue Logik kennt. Erhöhte Salzmengen 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 rechenintensiver wird dieser Ansatz.

Die Authentifizierung falscher Kennwörter ist mit den höchsten CPU-Kosten verbunden. Dies kann zu legitimen Anfragen kontraproduktiv sein, erhöht jedoch die Sicherheit gegen Angreifer.

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

33
Ibraheem

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 Salt zu verwenden, damit keine einzelne Rainbow-Tabelle für Ihre gesamte Gruppe von Kennwort-Hashes verwendet werden kann. Mit zufälligen Salzen muss ein Angreifer jeden Hash separat brute-force (oder eine Rainbow-Tabelle 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.

23
Andrew Medico

Basierend auf der Entwicklung des Buches ASP.NET MVC 4 Web Applications 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 Salz und das gesalzene Kennwort 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 beinhaltet, das Hacken in das System zu teuer oder zeitaufwendig 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 sich die Salze in derselben Datenbank befinden wie die gehashten Passwörter. Sie müssten nicht sicherstellen, dass zwei Datenbanken immer zur gleichen Zeit 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 Passworts einer Person erleichtern könnte, ist der erforderliche Kraftaufwand zum Knacken der Passwö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 dieser Stelle geht es darum, die Risiken der Benutzer aufgrund des Potenzials gemeinsamer Kennwörter zu verringern.
  3. Das Erfordernis, zwei getrennt verknüpfte Datenbanken zu führen, 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 dafür dasselbe Salt verwendet würde, wäre es sinnvoller, es getrennt von den Daten zu speichern, da die grundlegende Sicherheit Ihres Systems verbessert wird.
4
DaNeSh

Der Sinn eines Salzes besteht darin, alle Rainbow-Tische unbrauchbar zu machen und einen neuen Satz von ihnen zu erstellen. Das Erraten eines Strings dauert genauso lange wie das Erstellen einer Rainbow-Tabelle. Der SHA-256-Hash von "password" lautet beispielsweise 5e88 4898 da28 0471 51d0 e56f 8dc6 2927 7360 3d0d 6aab bdd6 2a11 ef72 1d15 42d8. Nach dem Hinzufügen eines Salt wie "badpassword" lautet die neue zu hashende Zeichenfolge "passwordbadpassword", was aufgrund des Lawineneffekts die Ausgabe dramatisch in 457b f8b5 37f1 802e f9c8 2e46 b8d3 f8b5 721b 7cbb d485 f0bb e523 bfbe 73e6 58d6 Ändert.

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

0
Eric Jin