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

Bei der Arbeit haben wir zwei konkurrierende Theorien für Salze. Die Produkte, an denen ich arbeite, verwenden so etwas wie einen Benutzernamen oder eine Telefonnummer, um den Hash zu salzen. Im Wesentlichen etwas, das für jeden Benutzer anders ist, aber für uns leicht verfügbar ist. Das andere Produkt generiert zufällig ein Salz für jeden Benutzer und ändert sich 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 rein theoretischer Sicht verstehen, dass es sicherer ist als der erste Ansatz, aber was ist aus praktischer Sicht? Um einen Benutzer zu authentifizieren, muss das Salt jetzt unverschlüsselt und auf die Anmeldeinformationen angewendet werden.

Nachdem ich darüber nachgedacht habe, sehe ich keinen wirklichen Sicherheitsgewinn durch diesen Ansatz. Das Ändern des Salt von Konto zu Konto macht es für jemanden immer noch äußerst schwierig, den Hashing-Algorithmus brutal zu erzwingen, selbst wenn der Angreifer wusste, wie er schnell feststellen kann, was es für jedes Konto ist. Dies setzt voraus, dass die Passwörter ausreichend sicher sind. (Offensichtlich ist es wesentlich einfacher, den richtigen Hash für eine Reihe von Passwörtern zu finden, bei denen es sich um alle zwei Ziffern handelt, als den richtigen Hash von Passwörtern mit 8 Ziffern zu finden.) Bin ich in meiner Logik falsch oder fehlt mir etwas?

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

Für die folgende Erklärung nehmen wir an, dass die Passwörter immer 8 Zeichen und das Salz 5 sind und alle Passwörter aus Kleinbuchstaben bestehen (dies erleichtert nur die Mathematik).

Ein anderes Salz für jeden Eintrag bedeutet, dass ich nicht denselben Regenbogentisch verwenden kann (technisch könnte ich das, wenn ich einen mit ausreichender Größe hätte, aber lassen Sie uns das für den Moment ignorieren). Dies ist der wahre Schlüssel zum Salz nach meinem Verständnis, denn um jeden Account zu knacken, muss ich das Rad sozusagen für jeden neu erfinden. Wenn ich nun weiß, wie man das richtige Salt auf ein Passwort anwendet, um den Hash zu generieren, würde ich es tun, weil ein Salt wirklich nur die Länge / Komplexität der Hash-Phrase erweitert. Ich würde also die Anzahl der möglichen Kombinationen reduzieren, die ich generieren müsste, um zu "wissen", dass ich das Passwort + Salz von 13 ^ 26 auf 8 ^ 26 habe, weil ich weiß, was das Salz ist. Das macht es einfacher, aber immer noch sehr schwer.

Also auf das Salz verschlüsseln. Wenn ich weiß, dass das Salz verschlüsselt ist, würde ich nicht zuerst versuchen, es zu entschlüsseln (vorausgesetzt, ich weiß, dass es über eine ausreichende Verschlüsselungsstufe verfügt). Ich würde es ignorieren. Anstatt herauszufinden, wie man es entschlüsselt, würde ich beim Zurückkehren zum vorherigen Beispiel einfach eine größere Regenbogentabelle generieren, die alle Schlüssel für die 13 ^ 26 enthält. Nicht zu wissen, dass das Salz mich definitiv verlangsamen würde, aber ich denke nicht, dass es die monumentale Aufgabe hinzufügen würde, zuerst zu versuchen, die Salzverschlüsselung zu knacken. Deshalb denke ich nicht, dass es das wert ist. Gedanken?

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

Die Antwort hier ist, sich zu fragen, wovor Sie wirklich schützen wollen. Wenn jemand Zugriff auf Ihre Datenbank hat, hat er Zugriff auf die verschlüsselten Salze und wahrscheinlich auch 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 zu machen, so dass es nicht möglich ist, eine Regenbogentabelle zu erstellen, um Ihre gesamte Passwortdatenbank auf einmal zu knacken, wenn sie aufgebrochen wird. Unter diesem Gesichtspunkt wäre ein Brute-Force-Angriff mit Ihren Salzen oder den verschlüsselten Salzen für jedes Passwort einzeln erforderlich, solange jedes Salz einzigartig ist.

Ein Salz zu verstecken ist unnötig.

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

Aus einer früheren Antwort von mir :

Salt hilft, vorberechnete Wörterbuchangriffe zu vereiteln.

Angenommen, ein Angreifer verfügt über eine Liste wahrscheinlicher Kennwörter. Er kann jeden hashen und ihn mit dem Hash des Passworts seines Opfers vergleichen und prüfen, ob es übereinstimmt. Wenn die Liste groß ist, kann dies lange dauern. Er möchte nicht so viel Zeit mit seinem nächsten Ziel verbringen, also zeichnet er das Ergebnis in einem "Wörterbuch" auf, in dem ein Hash auf die entsprechende Eingabe verweist. Wenn die Liste der Passwörter sehr, sehr lang ist, kann er Techniken wie eine Regenbogentabelle verwenden, um 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 und das Salz des Ziels an der Eingabe anbringen. Für jedes Salz ist ein anderes Wörterbuch erforderlich. Wenn genügend Salz verwendet wird, hat der Angreifer keinen Platz, um Wörterbücher für alle zu speichern. Der Handel mit Platz, um Zeit zu sparen, ist keine Option mehr. Der Angreifer muss auf jedes Passwort in seiner Liste für jedes Ziel zurückgreifen, das er angreifen möchte.

Es ist also nicht notwendig, das Salz geheim zu halten. Es reicht aus, sicherzustellen, dass der Angreifer kein vorberechnetes Wörterbuch hat, das diesem bestimmten Salz entspricht.

Nachdem ich ein bisschen mehr darüber nachgedacht habe, habe ich festgestellt, dass es gefährlich ist, sich zu täuschen, dass das Salz versteckt sein kann. Es ist viel besser anzunehmen, dass das Salz nicht verborgen werden kann, und das System trotzdem so zu gestalten, dass es sicher ist. Eine ausführlichere Erklärung gebe ich in einer anderen Antwort.

Jüngste Empfehlungen von NIST empfehlen jedoch die Verwendung eines zusätzlichen, geheimen "Salzes" (ich habe gesehen, dass andere dieses zusätzliche geheime "Pfeffer" nennen). Eine zusätzliche Iteration der Schlüsselableitung kann unter Verwendung dieses Geheimnisses als Salz durchgeführt werden. Anstatt die Stärke gegen einen vorberechneten Suchangriff zu erhöhen, schützt diese Runde vor dem Erraten von Passwörtern, ähnlich wie die große Anzahl von Iterationen in einer guten Schlüsselableitungsfunktion. Dieses Geheimnis hat keinen Zweck, wenn es mit dem Hash-Passwort gespeichert wird. Es muss als Geheimnis verwaltet werden, und das kann in einer großen Benutzerdatenbank schwierig sein.

Mein Verständnis von "Salz" ist, dass es das Knacken schwieriger macht, aber nicht versucht, die zusätzlichen Daten zu verbergen. Wenn Sie versuchen, mehr Sicherheit zu erhalten, indem Sie das Salz "geheim" machen, dann möchten Sie wirklich nur mehr Bits in Ihren Verschlüsselungsschlüsseln.

Der zweite Ansatz ist nur geringfügig sicherer. Salze schützen Benutzer vor Wörterbuchangriffen und Regenbogentischangriffen. Sie erschweren es einem ehrgeizigen Angreifer, Ihr gesamtes System zu gefährden, sind jedoch weiterhin anfällig für Angriffe, die sich auf einen Benutzer Ihres Systems konzentrieren. Wenn Sie öffentlich verfügbare Informationen wie eine Telefonnummer verwenden und der Angreifer davon Kenntnis erlangt , haben Sie ihm einen Schritt in seinem Angriff erspart. Natürlich ist die Frage umstritten, ob der Angreifer Ihre gesamte Datenbank, Salze und alles erhält.

BEARBEITEN: Nachdem ich diese Antwort und einige der Kommentare noch einmal durchgelesen habe, fällt mir ein, dass ein Teil der Verwirrung auf die Tatsache zurückzuführen ist, dass ich nur die beiden in der Frage dargestellten sehr spezifischen Fälle vergleiche: zufälliges Salz vs. nicht zufälliges Salz. Die Frage , eine Telefonnummer als Salz zu verwenden, ist umstritten, wenn der Angreifer Ihre gesamte Datenbank erhält, nicht die Frage, ob überhaupt ein Salz verwendet wird .

... so 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 rein theoretischer Sicht 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 erfasst oder verwaltet werden - und sich manchmal sowohl Benutzernamen als auch Telefonnummern ändern, um Ihre genauen Beispiele zu verwenden -, haben Sie möglicherweise Ihre Sicherheit gefährdet. Möchten Sie, dass eine solche nach außen gerichtete Änderung viel tiefere Sicherheitsbedenken hat?

Muss das Stoppen der Anforderung, dass jedes Konto eine Telefonnummer hat, eine vollständige Sicherheitsüberprüfung beinhalten, um sicherzustellen, dass Sie diese Konten nicht für einen Sicherheitskompromiss geöffnet haben?

Ein verstecktes Salz ist kein Salz mehr. Es ist Pfeffer. Es hat seine Verwendung. Es ist anders als Salz.

Pepper ist ein geheimer Schlüssel, der dem Passwort + Salt hinzugefügt wird und den Hash in einen HMAC (Hash Based Message Authentication Code) verwandelt. Ein Hacker mit Zugriff auf die Hash-Ausgabe und das Salt kann theoretisch eine Eingabe erraten, die den Hash generiert (und daher die Validierung im Kennwort-Textfeld besteht). Durch Hinzufügen von Pfeffer vergrößern Sie den Problembereich auf kryptografisch zufällige Weise und machen das Problem ohne ernsthafte Hardware unlösbar.

Weitere Informationen zu Pfeffer finden Sie hier .

Siehe auch hmac .

Hier ist ein einfaches Beispiel, das zeigt, warum es schlecht ist, für jeden Hash das gleiche Salz zu haben

Betrachten Sie die folgende Tabelle

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

Fall 1, wenn Salt 1 mit Salt2 identisch ist Wenn Hash2 durch Hash1 ersetzt wird, kann sich Benutzer 2 mit dem Kennwort von Benutzer 1 anmelden

Fall 2, wenn Salt 1 nicht dasselbe Salt2 ist Wenn Hash2 durch Hash1 ersetzt wird, kann sich Benutzer2 nicht mit dem Kennwort von Benutzer 1 anmelden.

Es gibt zwei Techniken mit unterschiedlichen Zielen:

• Das "Salz" wird verwendet, um zwei ansonsten gleiche Passwörter unterschiedlich zu verschlüsseln. Auf diese Weise kann ein Eindringling einen Wörterbuchangriff gegen eine ganze Liste verschlüsselter Kennwörter nicht effizient einsetzen.

• Das (geteilte) "Geheimnis" wird hinzugefügt, bevor eine Nachricht gehasht wird, sodass ein Eindringling seine eigenen Nachrichten nicht erstellen und akzeptieren kann.

Ich neige dazu, das Salz zu verstecken. Ich verwende 10 Bit Salz, indem ich eine Zufallszahl von 1 bis 1024 vor den Anfang des Passworts stelle, bevor ich es hashe. Wenn ich das vom Benutzer eingegebene Passwort mit dem Hash vergleiche, schleife ich von 1 bis 1024 und versuche jeden möglichen Salzwert, bis ich die Übereinstimmung finde. Dies dauert weniger als 1/10 Sekunde. Ich hatte die Idee, dies auf diese Weise von PHP password_hash und password_verify zu tun . In meinem Beispiel betragen die "Kosten" 10 für 10 Bit Salz. Oder nach dem, was ein anderer Benutzer gesagt hat, heißt verstecktes "Salz" "Pfeffer". Das Salz ist in der Datenbank nicht verschlüsselt. Es ist brutal rausgezwungen. Es würde die Regenbogentabelle notwendig machen, um den Hash 1000-mal größer umzukehren. Ich benutze sha256, weil es schnell ist, aber immer noch als sicher gilt.

Es hängt wirklich davon ab, vor welcher Art von Angriff Sie Ihre Daten schützen möchten.

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

Das Verschlüsseln des eindeutigen Salt für jedes Passwort würde es schwieriger machen, ein individuelles Passwort zu knacken, ja, aber Sie müssen abwägen, ob es wirklich einen großen Vorteil gibt. Wenn der Angreifer mit brutaler Gewalt feststellt, dass diese Zeichenfolge:

Marianne2ae85fb5d

Hashes zu einem in der DB gespeicherten Hash. Ist es wirklich so schwer herauszufinden, welcher Teil der Pass und welcher Teil das Salz ist?