Nicht zufälliges Salz für Passwort-Hashes

UPDATE: Ich habe kürzlich aus dieser Frage gelernt , dass ich (und ich bin sicher, dass andere dies auch getan haben) in der gesamten folgenden Diskussion etwas verwirrend war: Was ich immer wieder als Regenbogentabelle bezeichne, wird tatsächlich als Hash-Tabelle bezeichnet. Regenbogentabellen sind komplexere Kreaturen und tatsächlich eine Variante von Hellman Hash Chains. Obwohl ich glaube, dass die Antwort immer noch dieselbe ist (da es sich nicht um eine Kryptoanalyse handelt), könnte ein Teil der Diskussion etwas verzerrt sein.
Die Frage: " Was sind Regenbogentische und wie werden sie verwendet? "

Normalerweise empfehle ich immer, einen kryptografisch starken Zufallswert als Salt zu verwenden, um ihn mit Hash-Funktionen (z. B. für Passwörter) zu verwenden, z. B. zum Schutz vor Rainbow Table-Angriffen.

Aber ist es tatsächlich kryptografisch notwendig, dass das Salz zufällig ist? Würde ein eindeutiger Wert (eindeutig pro Benutzer, z. B. Benutzer-ID) in dieser Hinsicht ausreichen? Es würde in der Tat verhindern, dass eine einzige Regenbogentabelle verwendet wird, um alle (oder die meisten) Passwörter im System zu knacken ...
Aber schwächt mangelnde Entropie wirklich die kryptografische Stärke der Hash-Funktionen?

Hinweis: Ich frage nicht, warum ich Salz verwenden soll, wie ich es schützen soll (muss es nicht sein), einen einzelnen konstanten Hash verwenden (nicht) oder welche Art von Hash-Funktion ich verwenden soll.
Nur ob Salz Entropie braucht oder nicht.

Vielen Dank für die bisherigen Antworten, aber ich möchte mich auf die Bereiche konzentrieren, mit denen ich (ein wenig) weniger vertraut bin. Hauptsächlich Implikationen für die Kryptoanalyse - Ich würde mich am meisten freuen, wenn jemand einen Beitrag vom krypto-mathematischen PoV hat.
Wenn es zusätzliche Vektoren gibt, die nicht berücksichtigt wurden, ist dies ebenfalls eine großartige Eingabe (siehe @ Dave Sherohman-Punkt auf mehreren Systemen).
Wenn Sie darüber hinaus eine Theorie, Idee oder Best Practice haben, stützen Sie diese bitte entweder mit Beweisen, Angriffsszenarien oder empirischen Beweisen. Oder sogar gültige Überlegungen für akzeptable Kompromisse ... Ich bin mit Best Practice (Kapital B Kapital P) zu diesem Thema vertraut. Ich möchte beweisen, welchen Wert dies tatsächlich bietet.

EDIT: Einige wirklich gute Antworten hier, aber ich denke, wie @Dave sagt, kommt es auf Rainbow Tables für gebräuchliche Benutzernamen an ... und möglicherweise auch weniger gebräuchliche Namen. Was ist jedoch, wenn meine Benutzernamen global eindeutig sind? Nicht unbedingt eindeutig für mein System, sondern für jeden Benutzer - z. B. E-Mail-Adresse.
Es würde keinen Anreiz geben, eine RT für einen einzelnen Benutzer zu erstellen (wie @ Dave betont hat, wird das Salz nicht geheim gehalten), und dies würde immer noch das Clustering verhindern. Das einzige Problem wäre, dass ich möglicherweise dieselbe E-Mail-Adresse und dasselbe Passwort auf einer anderen Site habe - aber Salt würde das sowieso nicht verhindern.
Es kommt also wieder auf die Kryptoanalyse an - IST die Entropie notwendig oder nicht? (Mein derzeitiges Denken ist, dass es aus Sicht der Kryptoanalyse nicht notwendig ist, aber aus anderen praktischen Gründen.)

Salt wird traditionell als Präfix zum Hash-Passwort gespeichert. Dies macht es bereits jedem Angreifer mit Zugriff auf den Passwort-Hash bekannt. Die Verwendung des Benutzernamens als Salt oder nicht wirkt sich nicht auf dieses Wissen aus und hat daher keine Auswirkungen auf die Sicherheit eines einzelnen Systems.

Die Verwendung des Benutzernamens oder eines anderen benutzergesteuerten Werts als Salt würde jedoch die systemübergreifende Sicherheit verringern, da ein Benutzer, der auf mehreren Systemen, die denselben Kennwort-Hashing-Algorithmus verwenden, denselben Benutzernamen und dasselbe Kennwort hatte, denselben Kennwort-Hash erhalten würde jedes dieser Systeme. Ich halte dies nicht für eine erhebliche Haftung, da ich als Angreifer zuerst Kennwörter ausprobieren würde, die ein Zielkonto bekanntermaßen auf anderen Systemen verwendet hat, bevor ich andere Mittel zur Gefährdung des Kontos versuche. Identische Hashes würden mir nur im Voraus sagen, dass das bekannte Passwort funktionieren würde, sie würden den eigentlichen Angriff nicht einfacher machen. (Beachten Sie jedoch, dass ein schneller Vergleich der Kontodatenbanken eine Liste von Zielen mit höherer Priorität liefern würde, da ich erfahren würde, wer Kennwörter wiederverwendet und wer nicht.)

Die größere Gefahr dieser Idee besteht darin, dass Benutzernamen häufig wiederverwendet werden. Nahezu jede Site, die Sie besuchen möchten, verfügt beispielsweise über ein Benutzerkonto mit dem Namen "Dave", und "admin" oder "root" sind noch häufiger anzutreffen Die Erstellung von Regenbogentabellen für Benutzer mit diesen gebräuchlichen Namen ist viel einfacher und effektiver.

Diese beiden Fehler können effektiv behoben werden, indem dem Kennwort vor dem Hashing ein zweiter Salzwert hinzugefügt wird (entweder fest und verborgen oder wie Standardsalz verfügbar). An diesem Punkt können Sie jedoch auch nur Standard-Entropiesalz verwenden den Benutzernamen hinein zu arbeiten.

Bearbeitet, um hinzuzufügen: Viele Leute sprechen über Entropie und ob Entropie in Salz wichtig ist. Es ist, aber nicht aus dem Grund, warum die meisten Kommentare dazu zu denken scheinen.

Der allgemeine Gedanke scheint zu sein, dass Entropie wichtig ist, damit das Salz für einen Angreifer schwer zu erraten ist. Dies ist falsch und in der Tat völlig irrelevant. Wie einige Male darauf hingewiesen haben, können Angriffe, die von Salt betroffen sind, nur von jemandem mit der Passwortdatenbank ausgeführt werden, und jemand mit der Passwortdatenbank kann nur nachsehen, wie hoch das Salz jedes Kontos ist. Ob es erraten wird oder nicht, spielt keine Rolle, wann Sie es trivial nachschlagen können.

Der Grund, warum Entropie wichtig ist, besteht darin, eine Häufung von Salzwerten zu vermeiden. Wenn das Salz auf dem Benutzernamen basiert und Sie wissen, dass die meisten Systeme ein Konto mit dem Namen "root" oder "admin" haben, können Sie eine Regenbogentabelle für diese beiden Salze erstellen und die meisten Systeme knacken. Wenn andererseits ein zufälliges 16-Bit-Salz verwendet wird und die zufälligen Werte ungefähr gleichmäßig verteilt sind, benötigen Sie eine Regenbogentabelle für alle 2 ^ 16 möglichen Salze.

Es geht nicht darum, den Angreifer daran zu hindern, zu wissen, was das Salz eines einzelnen Kontos ist, sondern darum, ihm nicht das große, fette Ziel eines einzelnen Salzes zu geben, das für einen erheblichen Teil der potenziellen Ziele verwendet wird.

Die Verwendung eines Salzes mit hoher Entropie ist unbedingt erforderlich, um Passwörter sicher zu speichern.

Nimm meinen Benutzernamen 'gs' und füge ihn meinem Passwort hinzu. 'MyPassword' gibt gsMyPassword. Dies kann mit einer Regenbogentabelle leicht behoben werden, da der Wert möglicherweise nicht in der Regenbogentabelle gespeichert ist, wenn der Benutzername nicht genügend Entropie aufweist, insbesondere wenn der Benutzername kurz ist.

Ein weiteres Problem sind Angriffe, bei denen Sie wissen, dass ein Benutzer an zwei oder mehr Diensten teilnimmt. Es gibt viele gebräuchliche Benutzernamen, die wahrscheinlich wichtigsten sind admin und root. Wenn jemand eine Regenbogentabelle mit Salzen mit den häufigsten Benutzernamen erstellt hat, kann er diese verwenden, um Konten zu gefährden.

Früher hatten sie ein 12-Bit-Salz . 12 Bit sind 4096 verschiedene Kombinationen. Das war nicht sicher genug, da heutzutage so viele Informationen leicht gespeichert werden können . Gleiches gilt für die 4096 am häufigsten verwendeten Benutzernamen. Es ist wahrscheinlich, dass einige Ihrer Benutzer einen Benutzernamen auswählen, der zu den häufigsten Benutzernamen gehört.

Ich habe diesen Passwortprüfer gefunden , der die Entropie Ihres Passworts ermittelt. Eine geringere Entropie in Passwörtern (z. B. durch die Verwendung von Benutzernamen) erleichtert Regenbogentabellen erheblich, da sie versuchen, mindestens alle Passwörter mit geringer Entropie abzudecken, da sie mit größerer Wahrscheinlichkeit auftreten.

Es ist wahr, dass der Benutzername allein problematisch sein kann, da Benutzer Benutzernamen auf verschiedenen Websites teilen können. Es sollte jedoch eher unproblematisch sein, wenn die Benutzer auf jeder Website einen anderen Namen hatten. Warum also nicht einfach auf jeder Website einzigartig machen? Hash das Passwort etwas wie folgt

Hash-Funktion ("www.yourpage.com /" + Benutzername + "/" + Passwort)

Dies sollte das Problem lösen. Ich bin kein Meister der Kryptoanalyse, aber ich bezweifle, dass die Tatsache, dass wir keine hohe Entropie verwenden, den Hash schwächer machen würde.

Ich verwende gerne beides: ein zufälliges Salz mit hoher Entropie pro Datensatz sowie die eindeutige ID des Datensatzes selbst.

Dies erhöht zwar nicht viel die Sicherheit gegen Wörterbuchangriffe usw., entfernt jedoch den Randfall, in dem jemand sein Salz und seinen Hash in einen anderen Datensatz kopiert, um das Kennwort durch sein eigenes zu ersetzen.

(Zugegeben, es ist schwer, sich einen Umstand vorzustellen, unter dem dies zutrifft, aber ich kann keinen Schaden an Gürteln und Hosenträgern sehen, wenn es um Sicherheit geht.)

Wenn das Salz bekannt oder leicht zu erraten ist, haben Sie die Schwierigkeit eines Wörterbuchangriffs nicht erhöht. Es kann sogar möglich sein, eine modifizierte Regenbogentabelle zu erstellen, die ein "konstantes" Salz berücksichtigt.

Die Verwendung einzigartiger Salze erhöht die Schwierigkeit von BULK-Wörterbuchangriffen.

Ein einzigartiger, kryptographisch starker Salzwert wäre ideal.

Ich würde sagen, solange das Salz für jedes Passwort unterschiedlich ist, werden Sie wahrscheinlich in Ordnung sein. Der Punkt des Salzes ist, dass Sie nicht die Standard-Regenbogentabelle verwenden können, um jedes Passwort in der Datenbank zu lösen. Wenn Sie also jedem Passwort ein anderes Salt zuweisen (auch wenn es nicht zufällig ist), müsste der Angreifer grundsätzlich für jedes Passwort eine neue Regenbogentabelle berechnen, da jedes Passwort ein anderes Salt verwendet.

Die Verwendung eines Salzes mit mehr Entropie hilft nicht viel, da davon ausgegangen wird, dass der Angreifer in diesem Fall bereits über die Datenbank verfügt. Da Sie in der Lage sein müssen, den Hash neu zu erstellen, müssen Sie bereits wissen, was das Salz ist. Sie müssen also das Salz oder die Werte, aus denen das Salz besteht, in Ihrer Datei speichern. In Systemen wie Linux ist die Methode zum Abrufen des Salzes bekannt, sodass es keinen Sinn macht, ein geheimes Salz zu haben. Sie müssen davon ausgehen, dass der Angreifer, der Ihre Hash-Werte hat, wahrscheinlich auch Ihre Salzwerte kennt.

Die Stärke einer Hash-Funktion wird nicht durch ihre Eingabe bestimmt!

Die Verwendung eines Salzes, das dem Angreifer bekannt ist, macht das Erstellen einer Regenbogentabelle (insbesondere für fest codierte Benutzernamen wie root ) natürlich attraktiver, schwächt aber den Hash nicht . Die Verwendung eines dem Angreifer unbekannten Salzes erschwert den Angriff auf das System.

Die Verkettung eines Benutzernamens und eines Kennworts bietet möglicherweise immer noch einen Eintrag für eine intelligente Regenbogentabelle. Daher ist es wahrscheinlich besser, ein Salz aus einer Reihe von Pseudozufallszeichen zu verwenden, die mit dem Hash-Kennwort gespeichert sind. Wenn ich beispielsweise den Benutzernamen "Kartoffel" und das Passwort "Bier" hätte, wäre die verkettete Eingabe für Ihren Hash "Potatobeer", was ein vernünftiger Eintrag für eine Regenbogentabelle ist.

Das Ändern des Salt bei jeder Änderung des Kennworts durch den Benutzer kann dazu beitragen, längere Angriffe abzuwehren, ebenso wie die Durchsetzung einer angemessenen Kennwortrichtlinie, z. B. Groß- und Kleinschreibung, Zeichensetzung, Mindestlänge, Änderung nach n Wochen.

Ich würde jedoch sagen, dass Ihre Wahl des Digest-Algorithmus wichtiger ist. Die Verwendung von SHA-512 wird sich für jemanden, der einen Regenbogentisch generiert, als schmerzhafter erweisen als beispielsweise MD5.

Salz sollte so viel Entropie wie möglich aufweisen, um sicherzustellen, dass bei einem mehrfachen Hash eines bestimmten Eingabewerts der resultierende Hash-Wert so nah wie möglich immer unterschiedlich ist.

Durch die Verwendung sich ständig ändernder Salzwerte mit möglichst viel Entropie im Salz wird sichergestellt, dass die Wahrscheinlichkeit von Hashing (z. B. Passwort + Salz) zu völlig unterschiedlichen Hashwerten führt.

Je weniger Entropie im Salz vorhanden ist, desto größer ist die Chance, dass Sie denselben Salzwert erzeugen, und desto größer ist somit die Chance, dass Sie denselben Hashwert erzeugen.

Es ist die Natur des Hash-Werts, "konstant" zu sein, wenn die Eingabe bekannt ist, und "konstant", die Wörterbuchangriffe oder Regenbogentabellen so effektiv machen. Indem der resultierende Hash-Wert so weit wie möglich variiert wird (indem hohe Entropiesalzwerte verwendet werden), wird sichergestellt, dass durch Hashing derselben Eingabe + zufälliges Salz viele verschiedene Hash-Werte erzielt werden, wodurch die Regenbogentabelle besiegt (oder zumindest die Wirksamkeit der Regenbogentabelle stark verringert) wird Anschläge.

Die Entropie ist der Punkt des Salzwerts.

Wenn hinter Salz eine einfache und reproduzierbare "Mathematik" steckt, dann ist es dasselbe, als ob das Salz nicht da wäre. Nur das Hinzufügen eines Zeitwerts sollte in Ordnung sein.