Die Notwendigkeit, das Salz für einen Hash zu verstecken

Question

Bei der Arbeit haben wir zwei konkurrierende Theorien für Salze. Die Produkte, an denen ich arbeite, verwenden einen Benutzernamen oder eine Telefonnummer, um den Hashwert zu salzen. Im Wesentlichen etwas, das für jeden Benutzer anders ist, aber für uns leicht verfügbar ist. Das andere Produkt generiert nach dem Zufallsprinzip für jeden Benutzer ein Salz und ändert es jedes Mal, wenn der Benutzer das Kennwort ändert. Das Salz wird dann in der Datenbank verschlüsselt.

Meine Frage ist, ob der zweite Ansatz wirklich notwendig ist? Ich kann aus einer rein theoretischen Perspektive verstehen, dass es sicherer ist als der erste Ansatz, aber was ist aus praktischer Sicht. Um jetzt einen Benutzer zu authentifizieren, muss das Salz unverschlüsselt und auf die Anmeldeinformationen angewendet werden.

Nachdem ich darüber nachgedacht habe, sehe ich keinen wirklichen Sicherheitsgewinn von diesem Ansatz. Das Ändern des Salt von Konto zu Konto macht es immer noch extrem schwierig für jemanden, den Hashalgorithmus brutal zu erzwingen, auch wenn der Angreifer wusste, wie schnell er für jedes Konto ermitteln konnte. Dies geht davon aus, dass die Passwörter ausreichend stark sind. (Offensichtlich ist das Finden des korrekten Hash für eine Gruppe von Passwörtern, wo sie alle zwei Ziffern sind, wesentlich einfacher als das Finden des korrekten Hashs von Passwörtern, die 8 Ziffern sind). Bin ich falsch in meiner Logik oder gibt es etwas, das ich vermisse?

EDIT: Okay, also hier ist der Grund, warum ich denke, es ist wirklich strittig, das Salz zu verschlüsseln. (Ich weiß, ob ich auf dem richtigen Weg bin).

Für die folgende Erklärung gehen wir davon aus, dass die Passwörter immer 8 Zeichen lang sind und das Salt 5 ist und alle Passwörter aus Kleinbuchstaben bestehen (das erleichtert die Mathematik einfach).

Mit einem anderen Salz für jeden Eintrag bedeutet, dass ich nicht die gleiche Rainbow-Tabelle verwenden kann (eigentlich könnte ich technisch, wenn ich eine ausreichende Größe hätte, aber ignorieren wir das im Moment). Dies ist der wahre Schlüssel zum Salz von dem, was ich verstehe, denn um jeden Bericht zu knacken, muss ich das Rad sozusagen für jeden neu erfinden. Wenn ich nun weiß, wie man das richtige Salz auf ein Passwort anwendet, um den Hash zu erzeugen, würde ich es tun, weil ein Salz wirklich nur die Länge/Komplexität der Hash-Phrase verlängert. Also würde ich die Anzahl der möglichen Kombinationen reduzieren, die ich erzeugen müsste, um "wissen" zu können, dass ich das Passwort + Salz von 13^26 bis 8^26 habe, weil ich weiß, was das Salz ist. Nun, das macht es einfacher, aber immer noch sehr schwer.

Also auf die Verschlüsselung des Salzes. Wenn ich weiß, dass das Salz verschlüsselt ist, würde ich es zuerst nicht versuchen und entschlüsseln (vorausgesetzt, ich weiß, dass es ein ausreichendes Maß an Verschlüsselung hat). Ich würde es ignorieren. Anstatt zu versuchen, herauszufinden, wie man es entschlüsseln kann, gehe ich zum vorherigen Beispiel zurück und erzeuge einfach eine größere Rainbow-Tabelle, die alle Schlüssel für das 13^26 enthält. Das Salz nicht zu kennen würde mich definitiv bremsen, aber ich denke nicht, dass es die monumentale Aufgabe, die Salzverschlüsselung zuerst zu knacken, hinzufügen würde. Deshalb denke ich nicht, dass es das wert ist. Gedanken?

Hier ist ein Link zu beschreiben, wie lange Passwörter unter einem Brute-Force-Angriff halten werden: http://www.lockdown.co.uk/?pg=combi

Answer 1

Die Antwort hier ist, sich zu fragen, vor was Sie wirklich schützen möchten? Wenn jemand Zugriff auf Ihre Datenbank hat, hat er Zugriff auf die verschlüsselten Salze und hat wahrscheinlich auch Zugriff auf Ihren Code. Mit all dem konnten sie die verschlüsselten Salze entschlüsseln? Wenn ja, dann ist die Verschlüsselung sowieso ziemlich nutzlos. Das Salz ist wirklich da, um es so zu machen, dass es nicht möglich ist, einen Regenbogen-Tisch zu bilden, um Ihre gesamte Passwort-Datenbank in einem Rutsch zu knacken, wenn sie kaputt geht. Von diesem Standpunkt aus, solange jedes Salz einzigartig ist, gibt es keinen Unterschied, ein Brute-Force-Angriff wäre mit Ihren Salzen oder den verschlüsselten Salzen für jedes Passwort einzeln erforderlich.

Answer 2

Mein Verständnis von „Salz“ ist, dass es erschwert Knacken, aber es nicht versucht, das zu verbergen zusätzliche Daten Wenn Sie versuchen, mehr Sicherheit zu erhalten, indem Sie das Salt "geheim" machen, dann wollen Sie wirklich nur mehr Bits in Ihren Verschlüsselungsschlüsseln.

Answer 3

Es gibt zwei Techniken, mit unterschiedlichen Zielen:

• Das „Salz“ verwendet wird, um zwei ansonsten gleich Passwörter verschlüsseln anders zu machen.Auf diese Weise kann ein Eindringling einen Wörterbuchangriff gegen eine ganze Liste von verschlüsselten Passwörtern nicht effizient nutzen.

• Das (gemeinsam genutzte) "secret" wird vor dem Hashing einer Nachricht hinzugefügt, damit ein Eindringling keine eigenen Nachrichten erstellen und akzeptieren kann.

Answer 4

Der zweite Ansatz ist nur etwas sicherer. Salze schützen Benutzer vor Wörterbuchangriffen und Rainbow-Table-Angriffen. Sie machen es einem ambitionierten Angreifer schwerer, Ihr gesamtes System zu kompromittieren, sind aber dennoch anfällig für Angriffe, die sich auf einen Benutzer Ihres Systems konzentrieren. Wenn Sie Informationen verwenden, die öffentlich verfügbar sind, wie eine Telefonnummer, und der Angreifer diese erkennt, dann haben Sie sie einen Schritt in ihrem Angriff gespeichert. Natürlich ist die Frage, ob der Angreifer Ihre gesamte Datenbank, Salze und alles bekommt.

EDIT: Nach dem erneuten Lesen dieser Antwort und einige der Kommentare, kommt es mir vor, dass einige der Verwirrung aufgrund der Tatsache, dass ich nur die beiden sehr spezifischen Fällen in der präsentiert werden Frage: zufälliges Salz gegen nicht zufälliges Salz. Die Frage von mit einer Telefonnummer als Salz ist moot, wenn der Angreifer bekommt Ihre ganze Datenbank, nicht die Frage der Verwendung eines Salzes überhaupt.

Answer 5

Hier ist ein einfaches Beispiel zeigt, warum es schlecht ist für jeden Hash

Betrachten Sie die folgende Tabelle 1

UserId UserName, Password 
    1 Fred  Hash1 = Sha(Salt1+Password1)  
    2 Ted  Hash2 = Sha(Salt2+Password2)  

Fall 1, wenn Salz das gleiche Salz hat das gleiche wie salt2 ist Wenn Hash2 durch Hash1 ersetzt wird, könnte sich Benutzer 2 mit Benutzer 1 anmelden. Passwort

Fall 2, wenn Salz 1 nicht das gleiche Salz2 Wenn Hash2 durch Hash1 ersetzt wird, kann sich Benutzer2 nicht mit dem Kennwort des Benutzers 1 anmelden.

Answer 6

Wirklich, es hängt davon ab, welche Art von Angriff Sie versuchen, Ihre Daten zu schützen.

Der Zweck eines eindeutigen Salt für jedes Passwort besteht darin, einen Wörterbuchangriff auf die gesamte Passwortdatenbank zu verhindern.

Die Verschlüsselung des eindeutigen Salzes für jedes Passwort würde es schwieriger machen, ein individuelles Passwort zu knacken, aber Sie müssen abwägen, ob es wirklich einen großen Vorteil bringt. Wenn der Angreifer, mit brutalen Gewalt, stellt fest, dass diese Saite:

Marianne2ae85fb5d 

Hashes auf einen Hash in der DB gespeichert ist, ist es wirklich so schwer, herauszufinden, was der Teil der Pass ist und welcher Teil ist das Salz?

Answer 7

Das Verstecken eines Salzes ist nicht notwendig.

Für jeden Hash sollte ein anderes Salz verwendet werden. In der Praxis ist dies leicht zu erreichen, indem 8 oder mehr Bytes vom Zufallszahlengenerator mit kryptographischer Qualität erhalten werden.

Aus previous answer of mine:

Salz hilft vorausberechnete Wörterbuchangriffe zu vereiteln.

Angenommen, ein Angreifer hat eine Liste wahrscheinlicher Kennwörter. Er kann jede Hash und vergleichen Sie es mit dem Hash des Passworts seines Opfers, und sehen, ob es übereinstimmt. Wenn die Liste groß ist, kann dies lange dauern. Er braucht nicht so viel Zeit auf seinem nächsten Ziel zu verbringen, also zeichnet er das Ergebnis in einem "Wörterbuch" auf, wo ein Hash auf seinen entsprechenden Eingang zeigt. Wenn die Liste der Passwörter sehr, sehr lang ist, kann er Techniken wie eine Rainbow-Tabelle verwenden, um etwas Platz zu sparen.

Angenommen, sein nächstes Ziel hat sein Passwort gesalzen. Selbst wenn der Angreifer weiß, was das Salz ist, ist seine vorberechnete Tabelle wertlos - das Salz ändert den Hash, der sich aus jedem Passwort ergibt. Er muss alle Passwörter in seiner Liste erneut hashen, die Salz des Ziels an den Eingang anbringen. Jedes andere Salz benötigt ein anderes Wörterbuch, und wenn genug Salze verwendet werden, hat der Angreifer keinen Raum , um Wörterbücher für alle zu speichern. Handelsplatz, um Zeit zu sparen, ist keine länger eine Option; Der Angreifer muss jedes Passwort in seiner Liste für jedes Ziel, das er angreifen will, hashen.

Also ist es nicht notwendig, das Salz geheim zu halten. Sicherzustellen, dass der Angreifer kein vorberechnetes Wörterbuch hat, das dem bestimmten Salz entspricht, ist ausreichend.

---

darüber ein bisschen mehr Nach einigem Nachdenken, ich habe das selbst das Salz täuscht realisiert zu denken, versteckt gefährlich werden kann. Es ist viel besser anzunehmen, dass das Salz nicht versteckt werden kann, und das System dennoch so zu gestalten, dass es sicher ist. Ich gebe eine detailliertere Erklärung in another answer.

Answer 8

... etwas wie ein Benutzername oder eine Telefonnummer, um den Hash zu salzen. ...

Meine Frage ist, ob der zweite Ansatz wirklich notwendig ist? Ich kann aus einer rein theoretischen Perspektive verstehen, dass es sicherer ist als der erste Ansatz, aber was ist aus praktischer Sicht?

Aus praktischer Sicht ist ein Salz ein Implementierungsdetail. Wenn Sie jemals ändern, wie Benutzerinformationen gesammelt oder gepflegt werden – und beide Benutzernamen und Telefonnummern manchmal ändern, um Ihre exakten Beispiele – zu verwenden, dann haben Sie möglicherweise Ihre Sicherheit kompromittiert. Möchten Sie, dass eine solche nach außen gerichtete Veränderung zu viel tieferen Sicherheitsbedenken führt?

Muss das Anhalten der Anforderung, dass jedes Konto eine Telefonnummer hat, eine vollständige Sicherheitsüberprüfung enthalten, um sicherzustellen, dass Sie diese Konten nicht zu einer Sicherheitsgefährdung geöffnet haben?

Answer 9

Ein verstecktes Salz ist nicht mehr Salz. Es ist Pfeffer. Es hat seinen Nutzen. Es ist anders als Salz.

Pepper ist ein geheimer Schlüssel, der dem Passwort + salt hinzugefügt wird, wodurch der Hash zu einem HMAC (Hash Based Message Authentication Code) wird. Ein Hacker mit Zugriff auf die Hash-Ausgabe und das Salz kann theoretisch Brute Force eine Eingabe erraten, die den Hash generieren wird (und daher die Validierung in der Passwort-Textbox bestehen). Indem Sie Pfeffer hinzufügen, vergrößern Sie den Problembereich kryptografisch zufällig und machen das Problem ohne ernsthafte Hardware unlösbar.

Weitere Informationen zu Pfeffer finden Sie unter here.

Siehe auch hmac.