it-swarm.com.de

Die Notwendigkeit, das Salz für ein Haschisch 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. Grundsätzlich etwas, das für jeden Benutzer anders ist, aber für uns leicht verfügbar ist. Das andere Produkt generiert zufällig einen Salt für jeden Benutzer und ändert sich jedes Mal, wenn der Benutzer das Kennwort ändert. Das Salt 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 der Salt-Code unverschlüsselt sein und auf die Anmeldeinformationen angewendet werden. 

Nachdem ich darüber nachgedacht habe, sehe ich durch diesen Ansatz keinen echten Sicherheitsgewinn. Das Ändern des Salt-Werts von Konto zu Konto macht es für jemanden dennoch extrem schwierig, den Hash-Algorithmus zu erzwingen, selbst wenn der Angreifer wusste, wie er schnell feststellen kann, was für jedes Konto er war. Dies setzt voraus, dass die Passwörter ausreichend stark sind. (Natürlich ist es wesentlich einfacher, den richtigen Hash für einen Satz von Passwörtern zu finden, bei denen es sich um zwei Ziffern handelt, als um den richtigen Hash von Passwörtern (8 Ziffern) zu finden. Bin ich falsch in meiner Logik oder fehlt mir etwas?

EDIT: Okay, hier ist der Grund, warum ich denke, es ist wirklich eine Frage des Salzes. (lass mich wissen, ob ich auf dem richtigen Weg bin). 

Für die folgende Erklärung nehmen wir an, dass die Passwörter immer aus 8 Zeichen bestehen und der Salt-Wert 5 ist und alle Passwörter aus Kleinbuchstaben bestehen (dies vereinfacht die Berechnung nur).

Ein anderes Salt für jeden Eintrag bedeutet, dass ich nicht denselben Rainbow-Tisch verwenden kann (eigentlich könnte ich das, wenn ich einen von ausreichender Größe hätte, aber lassen wir das für den Moment ignorieren). Dies ist der eigentliche Schlüssel zum Salz aus dem, was ich verstehe, denn um jeden Account zu knacken, muss ich das Rad sozusagen für jeden neu erfinden. Wenn ich nun weiß, wie ich das richtige Salt auf ein Passwort anwenden kann, 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 muss, um zu wissen, dass ich das Passwort + Salt von 13 ^ 26 auf 8 ^ 26 habe, weil ich weiß, was das Salz ist. Das macht es jetzt einfacher, aber immer noch sehr schwer. 

Also das Salz verschlüsseln. Wenn ich weiß, dass das Salz verschlüsselt ist, würde ich es nicht zuerst versuchen und zu entschlüsseln (vorausgesetzt, ich weiß, dass es über eine ausreichende Verschlüsselung verfügt). Ich würde es ignorieren. Anstatt zu versuchen herauszufinden, wie man es entschlüsseln kann, würde ich, um zum vorherigen Beispiel zurückzukehren, einfach eine größere Rainbow-Tabelle generieren, die alle Schlüssel für die 13 ^ 26 enthält. Wenn ich das Salz nicht kenne, würde es mich definitiv verlangsamen, aber ich glaube nicht, dass es die monumentale Aufgabe wäre, zuerst die Salzverschlüsselung zu knacken. Deshalb glaube ich nicht, dass es das wert ist. Gedanken?

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

95
kemiller2002

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 hat wahrscheinlich auch Zugriff auf Ihren Code. Mit all dem konnten sie die verschlüsselten Salze entschlüsseln? Wenn ja, ist die Verschlüsselung sowieso ziemlich nutzlos. Das Salz ist wirklich dazu da, um es zu schaffen, so dass es nicht möglich ist, eine Rainbow-Tabelle zu bilden, um Ihre gesamte Passwort-Datenbank in einem Durchgang zu knacken, wenn in sie eingebrochen wird. Solange jedes Salz einzigartig ist, gibt es keinen Unterschied. Daher ist ein Brute-Force-Angriff mit Ihren Salzen oder den verschlüsselten Salzen für jedes Kennwort einzeln erforderlich.

42
tloach

Ein Salz zu verbergen ist nicht nötig.

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

Aus einer vorherigen Antwort von mir :

Salz hilft, vorberechnete Wörterbuchangriffe abzuwehren.

Angenommen, ein Angreifer verfügt über eine Liste wahrscheinlicher Kennwörter. Er kann jeden Hash und vergleichen Sie es mit dem Hash des Passworts seines Opfers, und sehen Sie, ob es Streichhölzer. Wenn die Liste groß ist, kann dies lange dauern. Er tut es nicht. Ich möchte so viel Zeit mit seinem nächsten Ziel verbringen, also zeichnet er das Ergebnis auf in einem "Wörterbuch", wo ein Hash auf seine entsprechende Eingabe zeigt. Ob Die Liste der Passwörter ist sehr, sehr lang, er kann Techniken wie ein .__ verwenden. Rainbow Table um Platz zu sparen.

Nehmen Sie jedoch an, sein nächstes Ziel hat sein Passwort gesalzen. Auch wenn die Angreifer weiß, was das Salz ist, seine vorberechnete Tabelle ist wertlos - der Salt ändert den Hash, der sich aus jedem Passwort ergibt. Er Hat alle Passwörter in seiner Liste erneut zu überprüfen, wobei die .__ des Ziels eingefügt wird. Salz zum Eingang. Jedes andere Salz erfordert ein anderes Wörterbuch, und wenn genug Salze verwendet werden, hat der Angreifer keinen Platz Wörterbücher für alle speichern. Um Platz zu sparen ist kein Platz länger eine Option; Der Angreifer muss jedes Kennwort zurücksetzen in seiner Liste für jedes Ziel, das er angreifen möchte.

Es ist also nicht notwendig, das Salz geheim zu halten. Sicherstellen, dass die Der Angreifer hat kein vorberechnetes Wörterbuch, das diesem .__ entspricht. bestimmtes Salz ist ausreichend.


Nachdem ich noch etwas darüber nachgedacht hatte, wurde mir klar, dass es gefährlich ist, sich zu täuschen, dass Salz versteckt werden kann. Es ist viel besser anzunehmen, dass das Salz nicht versteckt werden kann, und das System trotzdem so zu gestalten, dass es sicher ist. Ich gebe eine genauere Erklärung in einer anderen Antwort.

92
erickson

Ein verborgenes Salz ist kein Salz mehr. Es ist Pfeffer. Es hat seine Verwendung. Es unterscheidet sich von Salz.

Pepper ist ein geheimer Schlüssel, der zum Kennwort + Salt hinzugefügt wird, wodurch der Hash in einen HMAC (Hash Based Message Authentication Code) umgewandelt wird. Ein Hacker mit Zugriff auf die Hash-Ausgabe und das Salt kann theoretisch eine Eingabe erraten, die den Hash generiert (und somit die Validierung in der Kennwort-Textbox durchläuft). Durch das Hinzufügen von Pfeffer erhöhen Sie den Problembereich auf eine kryptografisch zufällige Weise, wodurch das Problem ohne ernsthafte Hardware unlösbar wird.

Weitere Informationen zu Pfeffer finden Sie unter hier .

Siehe auch hmac .

3
John Wu

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

3
gbarry

Der zweite Ansatz ist nur etwas sicherer. Salze schützen Benutzer vor Wörterbuchangriffen und Rainbow Table-Angriffen. Sie machen es einem ehrgeizigen Angreifer schwieriger, Ihr gesamtes System zu gefährden, sind jedoch immer noch anfällig für Angriffe, die auf einen Benutzer Ihres Systems gerichtet sind. Wenn Sie Informationen verwenden, die öffentlich verfügbar sind, z. B. eine Telefonnummer, und der Angreifer wird sich dessen bewusst, dann haben Sie ihnen einen Schritt bei ihrem Angriff erspart. Natürlich stellt sich die Frage, ob der Angreifer Ihre gesamte Datenbank, Ihre Salze und alle bekommt.

BEARBEITEN: Nachdem ich diese Antwort und einige Kommentare nochmals durchgelesen habe, kommt es mir auf den Grund, dass einige der Verwirrungen auf die Tatsache zurückzuführen sind, dass ich nur die beiden sehr spezifischen Fälle der Frage vergleiche: zufälliges Salz im Vergleich zu nicht zufälligem Salz. Die Frage von Verwendung einer Telefonnummer als Salt ist umstritten, wenn der Angreifer Ihre gesamte Datenbank erhält, und nicht die Frage, ob ein Salt überhaupt verwendet wird.

3
Bill the Lizard

... 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 wie sieht es aus praktischer Sicht aus?

Aus praktischer Sicht ist ein Salz ein Implementierungsdetail. Wenn Sie jemals ändern, wie Benutzerdaten gesammelt oder verwaltet werden, und sich sowohl die Benutzernamen als auch die Telefonnummern ändern, um Ihre exakten Beispiele zu verwenden, haben Sie möglicherweise Ihre Sicherheit beeinträchtigt. Möchten Sie, dass eine solche nach außen gerichtete Änderung tiefere Sicherheitsbedenken hat?

Muss das Erfordernis, dass jedes Konto eine Telefonnummer hat, gestoppt werden, ist eine vollständige Sicherheitsüberprüfung erforderlich, um sicherzustellen, dass Sie diese Konten nicht für einen Sicherheitsrisiko geöffnet haben.

2
Anon

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

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 Benutzer 1-Kennwort anmelden

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

2
Charles Faiga

Es gibt zwei Techniken mit unterschiedlichen Zielen:

  • Mit dem "Salt" werden zwei ansonsten gleiche Passwörter unterschiedlich verschlüsselt. Auf diese Weise kann ein Eindringling einen Wörterbuchangriff nicht effizient gegen eine ganze Liste verschlüsselter Kennwörter einsetzen.

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

1
Javier

Ich neige dazu, das Salz zu verstecken. Ich verwende 10 Bits Salt, indem ich dem Anfang des Passworts eine Zufallszahl von 1 bis 1024 voranstelle, bevor ich es hashte. Beim Vergleich des Passworts, das der Benutzer mit dem Hash eingegeben hat, verwende ich eine Schleife zwischen 1 und 1024 und versuche jeden möglichen Salzwert, bis ich die Übereinstimmung gefunden habe. Dies dauert weniger als 1/10 Sekunde. Ich hatte die Idee, dies so zu machen von PHP password_hash und password_verify . In meinem Beispiel betragen die "Kosten" 10 für 10 Bits Salz. Oder nach dem, was ein anderer Benutzer gesagt hat, wird "verstecktes" Salz "Pfeffer" genannt. Das Salt wird in der Datenbank nicht verschlüsselt. Es ist rausgedrückt. Es würde den Rainbow-Tisch notwendig machen, um den Hash 1000-mal größer zu machen. Ich verwende sha256, weil es schnell ist, aber dennoch als sicher angesehen wird.

0
Russell Hankins