Frage:
Lagert jemand kein Salz?
jazzpi
2016-07-15 14:33:58 UTC
view on stackexchange narkive permalink

Wir haben heute im Unterricht über Passwort-Hashing und Salting gesprochen. Unser Professor hatte ein ganz anderes Verständnis des Anwendungsfalls von Salzen als ich und sagte, dass Sie das Salz möglicherweise überhaupt nicht speichern und einfach jeden Anmeldeversuch mit allen möglichen Salzen überprüfen und autorisieren, ob eines übereinstimmt.

I. Ich sehe darin überhaupt keinen Sinn, da mein Dienst jetzt viel anfälliger für Brute-Force-Angriffe ist (senden Sie ein Passwort, Server überprüft viele), aber ich denke, es ist etwas sicherer für reine Wörterbuchangriffe gegen das Hash-Passwort.

Gibt es also einen Anwendungsfall, in dem die Leute dies tatsächlich tun würden?

In Anbetracht der Länge des Salzes kann dies zu einem sehr langen (unpraktischen) Anmeldevorgang führen, wenn Sie alle möglichen Salzwerte ausprobieren müssen.Dies führt zur Verwendung eines kleineren Salzbereichs für die Verwendbarkeit.Ich denke, dass dies zu einer schlechteren Sicherheit führen kann, als einen gültigen Salzwert zu verwenden und ihn zu speichern.Siehe auch https://stackoverflow.com/questions/184112/what-is-the-optimal-length-for-user-password-salt zur Diskussion der idealen Salzlänge, wobei zwischen 16 und 256 Bit vorgeschlagen werden.
Bestimmt.Wir haben ein 12-Bit-Salt verwendet, also nur 4096 Versuche, aber längere Salts bedeuten nicht nur eine längere Anmeldezeit, sondern auch eine schlechtere Sicherheit, da der Server versucht, Sie mit 2 ^ n Passwörtern anstelle von nur einem zu authentifizieren.
Wovon ist dieser Typ ein Professor?Zahnheilkunde?
Beachten Sie, dass ein guter kryptografischer Hash von Natur aus * langsam * ist, sodass der Bereich möglicher Salzwerte sehr bald zu groß wird.
Aus diesem Grund sollten Menschen von Stack Exchange anstelle von Professoren lernen.:-)
Wenn Ihr Anmeldevorgang brutales Erzwingen beinhaltet ... machen Sie es falsch.Der einzige Unterschied zwischen dem Verzicht auf Salz (schreckliche Idee) und dem Ausprobieren des gesamten Salzes (schreckliche Idee) besteht darin, dass man viel rechenintensiver sein wird (ärgern Sie Ihre Benutzer).
Das Speichern eines Salzes durch AFAIK ist eine schlechte Idee, wenn sich Ihre Datenbank an einem feuchten Ort befindet - führt zu Korrosion (siehe Beispiel einer korrodierten Tabelle in Second Life [hier] (https://slm-assets0.secondlife.com/assets/1123356/).Leuchtkasten / 65b45b42685a44ca64e556f353d48e4e.jpg? 1277194741)).
Ich nahm an, dass dies auf Cooking.SE war, als ich es im HNQ sah, bevor ich das kleine "InfoSec" -Symbol bemerkte: D.
@oɔɯǝɹ: Eine allgemeine kryptografische Hash-Funktion sollte vom Design her _fast_ sein.Deshalb sollten allgemeine Hash-Funktionen nicht für das Passwort-Hashing verwendet werden!
@cat Haha, ich auch.
Ihr Professor sollte lesen: http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190
@CaffeineAddiction: "Der einzige Unterschied zwischen dem Verzicht auf Salz (schreckliche Idee) und dem Ausprobieren des gesamten Salzes (schreckliche Idee) besteht darin, dass man viel rechenintensiver sein wird (ärgern Sie Ihre Benutzer)." Tatsächlich ist es noch schlimmer, alle Salze zu probieren, da Sie jetzt (im Fall von Jazzpi) 4096-mal häufiger auf eine Hash-Kollision stoßen.Ein ultra-sicheres Passwort ist irrelevant, wenn der gleiche Hash von einem Wörterbuchwort mit einem anderen Salz generiert wird.Vergessen Sie Brute-Force aufgrund bekannter Daten.Dies macht Ihre Anwendung ohne bekannte Daten weniger sicher.
leicht vom Thema abweichende Empfehlung.Zunächst bestätigen Sie, dass das, was Sie hier geschrieben haben, tatsächlich ist, was der Professor sagte.Wenn ja, dann schlage ich vor, dass Sie sich dem Dekan Ihrer Schule nähern und über einen Transfer / Rückerstattung sehen.Diese Person ist nicht qualifiziert, diese Klasse zu unterrichten.
Könnte Ihr Professor einfach gesagt haben, dass es möglich ist, kein Salz zu speichern, aber nicht gesagt hat, dass es eine gute Idee ist?
@Shadur Wahrscheinlich Komödie.
Kann es hier zu Verwirrung bei der Verwendung eines Pfeffers kommen?- d.h. ein Salz, das der Anwendung bekannt ist, aber nicht mit den Passwörtern in der Datenbank gespeichert ist?
@Jedi, Junge, ich habe wirklich lange gebraucht, um das zu bekommen.:) Ich habe es zuerst komplett übersehen.
Ihr Professor scheint keine Ahnung zu haben, wovon er spricht.Es wäre lustig gewesen, wenn Sie gefragt hätten, was er davon hält, vor dem Hashing etwas Koffein hinzuzufügen.
Neun antworten:
#1
+176
Gudradain
2016-07-15 17:29:34 UTC
view on stackexchange narkive permalink

Das Salz nicht zu speichern ist ein schlechter Rat.

Der Hauptzweck eines Salzes besteht darin, dass jedes Benutzerkennwort einzeln angegriffen werden muss.

Wenn Sie das Salz dann nicht speichern Wie Sie sagten, müssen Sie jede einzelne Salzkombination ausprobieren, um das Passwort zu validieren. Wenn Sie jede einzelne Salzkombination überprüfen müssen, bedeutet dies, dass das Salz nicht zu lang sein darf (Sie haben in einem Kommentar 12 Bits erwähnt). Wenn das Salz nicht lang ist, bedeutet dies, dass das Salz für viele Benutzer wiederholt wird. Wenn es für viele Benutzer wiederholt wird, bedeutet dies, dass der Angreifer viele Benutzer gleichzeitig angreifen kann, was dem Angreifer Zeit spart.

Auf diese Weise können Sie den Zweck der Verwendung von a fast vollständig zunichte machen Salz.

würde es nicht auch die Möglichkeit von mehr Kollisionen und viel mehr Fehlalarmen eröffnen?
@CaffeineAddiction Vielleicht.Zum Beispiel könnte Folgendes passieren: Hash (falsches Salz + falsches Passwort) = Hash (richtiges Salz + richtiges Passwort).Es ist jedoch kein praktischer Angriffsweg, da es ziemlich schwierig ist, eine Kollision in der Hash-Funktion zu erzeugen.
@CaffeineAddiction: nicht wahrscheinlich.Unter der Annahme von SHA-256 und einem 32-Bit-Salt ist Ihre Wahrscheinlichkeit einer Kollision mit dem vorhandenen Hash (auch bekannt als 2. Vorbild) von 2 ^ -256 auf 2 ^ -224 gestiegen.Größer, aber immer noch infinitesimal im großen Schema der Dinge.
@David wie?Hash-Funktionen können als zufällige Orakel modelliert werden, bei denen zwei beliebige Eingaben zu unabhängigen Ausgaben führen. Daher glaube ich, dass sich die Wahrscheinlichkeit überhaupt nicht ändert (es sei denn, Sie füllen Ihre Eingabe auf eine feste Länge auf).
@Thomas: ja, aber wenn das System 2 ^ 32 Salze versucht, bleibt die Wahrscheinlichkeit jeder Kollision gleich, aber die Gesamtwahrscheinlichkeit einer Kollision sollte um 2 ^ 32 verringert werden.
@Thomas Sie haben einen Hash generiert aus " ".Jedes Mal, wenn der Benutzer sein Passwort eingibt, überprüft der Server Ihr Passwort in Kombination mit den 2 ^ 32 möglichen Salzen.Wenn Sie zum Beispiel einen 32-Bit-Hash verwenden, würde dies bedeuten, dass Ihr echtes Passwort funktioniert, aber es besteht auch eine hervorragende Chance, dass der Hash mit einem der 2 ^ 32 übereinstimmt, die vom Server versucht wurden, wenn Sie ein beliebiges Passwort eingegeben haben.
@David Sie haben die Lektion des Geburtstagsparadoxons vergessen.Zufällige Prozesse kollidieren viel häufiger.Die Chancen gehen tatsächlich von 2 ^ -256 bis 2 ^ -193.Und das mit einem einzelnen Benutzer.Es klettert ziemlich schnell weiter, wenn Sie Benutzer hinzufügen.Trotzdem ist es ziemlich klein.
Denken Sie daran, dass Fehlalarme auch für den Angreifer ein Gewinn sind.Wenn sie ein anderes Passwort finden, das mit einem anderen Salz funktioniert, können sie es verwenden.Da alle Salze ausprobiert werden, können sie sich dennoch authentifizieren.
@AaronDufour, Das Geburtstagsparadoxon gilt nur, wenn Sie nach Kollisionen im Datensatz suchen.Dies ist wirklich eher ein Preimage-Angriff - sie versuchen, einen festen Wert zu erreichen.
#2
+126
amccormack
2016-07-15 19:14:41 UTC
view on stackexchange narkive permalink

Ein 'geheimes' Salz wird als Pfeffer bezeichnet.

Aus Wikipedia:

Ein Pfeffer kann einem Passwort in hinzugefügt werden Zusatz zu einem Salzwert. Ein Pfeffer spielt eine ähnliche Rolle wie ein Salz. Während ein Salz üblicherweise neben dem zu hashenden Wert gespeichert wird, sollte etwas, das als Pfeffer definiert werden soll, eines der folgenden Kriterien erfüllen, die es als sorgfältig verborgenes „Geheimnis“ definieren. als der Salzwert:

  • Der Pfeffer wird getrennt von dem zu hashenden Wert gehalten.
  • Der Pfeffer wird zufällig für jeden zu hashenden Wert erzeugt (innerhalb eines begrenzten Satzes von Werte) und wird nie gespeichert. Wenn Daten gegen einen Hash-Wert für eine Übereinstimmung getestet werden, wird dies durch Durchlaufen des für den Pfeffer gültigen Wertesatzes durchgeführt, und jeder wird der Reihe nach zu den zu testenden Daten hinzugefügt (normalerweise durch Anhängen an die Daten). Bevor die kryptografische Hash-Funktion für den kombinierten Wert ausgeführt wird.
/ blockquote>

Der Vorteil eines Pfeffers besteht darin, dass ein Angreifer jetzt die Anzahl der möglichen Permutationen eines Pfefferwerts erraten muss

Paprika erhöht die Angriffsdauer für einen bestimmten Hash, ein Salz dagegen nicht.

Denken Sie daran, dass ein Salz eine wirksame Abschwächung für vorberechnete Hashes darstellt Ein Angreifer greift lange Zeit eine Reihe von Hashes an. Wenn jedoch nur ein Hash von Belang ist und keine vorberechneten Hashes verwendet werden sollen, erhöht ein Salz die Angriffsdauer nicht. Ein Pepper zwingt den Angreifer jedoch, für jedes Klartext-Passwort mehrere Vermutungen anzustellen, selbst für einen einzelnen Hash.

Auf diese Weise ähnelt ein Pfeffer der Tastendehnung.

Die meisten Implementierungen bevorzugen das Strecken von Schlüsseln gegenüber Paprika.

Meine persönliche Beobachtung ist, dass die meisten Implementierungen das Dehnen von Schlüsseln gegenüber Paprika bevorzugen. Ich habe keine Referenz dafür, daher können die Leser in den Kommentaren unterstützende oder abweichende Referenzen angeben. Menschen bevorzugen das Stretching von Schlüsseln, da es bekannte und erwartete Leistungskosten und Sicherheitsvorteile bietet. Um die N-te Runde eines Hashs zu berechnen, müssen N-Hashes berechnet werden. Mit einem Pfeffer kann jedoch nur die erwartete Anzahl von Versuchen berechnet werden. Betrachten Sie einen 1-Byte-Pfeffer, der Angreifer würde 256 Vermutungen benötigen, um alle möglichen Kombinationen zu erraten, aber der erwartete Wert ist 128, und der Angreifer könnte (im Durchschnitt 1/256-mal) den Wert auf der erraten erster Versuch.

Peppers und Key Stretching können gegeneinander arbeiten.

Key Stretching ist effektiv, da Sie die Anzahl der Runden basierend auf der Zeitspanne festlegen können, für die die Berechnung eines Hashs erforderlich ist nehmen. Angenommen, Sie möchten, dass eine einzelne Überprüfung der aktuellen Hardware eine halbe Sekunde dauert. Erhöhen Sie einfach die Runden, bis dies eintritt.

Bei einem Pfeffer muss die Größe eines Pfeffers umgekehrt zur Anzahl der Runden stehen, da Sie für jedes Kennwort mehrere Werte erraten müssen, um die Rechenzeit konstant zu halten.

Praktische Ratschläge zu Hash-Implementierungen

Der beste Rat für Passwort- / Hash-Implementierungen ist die Verwendung bekannter Methoden und getesteter Bibliotheken. Sie sollten bcrypt oder pbkdf2 mit einem einzigartigen Salz und vielen Runden verwenden. Diese Algorithmen haben in der Regel bekannte Implementierungen in vielen Sprachen und Frameworks. Wenn Sie zufällig eine bekannte und getestete Bibliothek finden, die neben Salzen und Schlüsselstretching auch Pfeffer enthält, lohnt es sich möglicherweise, sie zu verwenden, aber der zusätzliche Vorteil überwiegt häufig die Leistungskosten.

würde es nicht auch die Möglichkeit von mehr Kollisionen und viel mehr Fehlalarmen eröffnen?
@CaffeineAddiction Ich muss zugeben, dass ich die Mathematik hinter diesen Hashing-Algorithmen nicht gut genug kenne, um zu beweisen, dass die Verwendung eines Pfeffers Kollisionen erhöhen oder verringern würde.Es ist eine gute Frage, und Sie erhalten möglicherweise eine bessere Antwort auf [crypto.se] (http://crypto.stackexchange.com/).Mein Gedanke ist, dass es Kollisionen wahrscheinlich nicht auf einen signifikanten Betrag erhöhen würde, wenn Sie 1) einen ausreichend großen Hashing-Algorithmus wie SHA-256 oder höher und 2) eine kleinere Pfeffergröße (weniger als 2 Bytes) verwenden würden.
Paprika wird jedoch weiterhin gespeichert (nicht in der Übersicht, sondern gespeichert)
@WoJ Der zweite Punkt im Wikipedia-Artikel weist darauf hin, dass der Pfeffer möglicherweise nicht gelagert wird.Ich habe versucht, eine bessere Referenz als Wikipedia zu finden, die einen Pfeffer beschreibt, konnte aber keine finden.Wenn Sie einen Hinweis darauf kennen, dass Pfeffer gelagert werden soll, würde ich ihn mir gerne ansehen.
@amccormack: Ich habe den Wikipedia-Artikel leider nicht gelesen.Das heißt, ich habe noch nie eine solche Implementierung eines Pfeffers gesehen (nachdem ich eine begrenzte Menge von ihnen gesehen habe).Dies wäre ein Albtraum, um zu überprüfen, ob der Hashing-Algorithmus korrekt ist (langsam, mehrrundig).
@Woj, Ich stimme zu, es würde einen Albtraum zum Testen machen und wahrscheinlich dazu führen, dass der Implementierer die Anzahl der Runden für jede Schlüsseldehnung verringert.Das Speichern des Salzes (oder das deterministische Berechnen) würde die negativen Auswirkungen auf das Strecken der Schlüssel verringern und könnte einige Fälle abmildern, in denen nur die Hash + Salz-Werte durchgesickert sind.
Wie ich immer gehört habe, dass "Pfeffer" definiert ist, ist ein Salz, das pro Anwendung im Code und nicht pro Benutzer in der Datenbank gespeichert wird.
Bemerkenswert ist, dass ein Pfeffer immer noch gespeichert ist, nur nicht unbedingt in der Datenbank.Das OP scheint von einem Fall zu sprechen, in dem das Salz überhaupt nicht gespeichert wird und die Anwendung das Salz bei jedem Anmeldeversuch im Wesentlichen brutal erzwingt ...
@Ajedi32 Vielen Dank für den Hinweis.Andere haben ebenfalls darauf hingewiesen, aber ich kann keine endgültige Quelle finden, die diese Behauptung aufstellt.Wenn Sie mich auf einen verweisen könnten, würde ich es schätzen.
@amccormack Ich bin mir nicht sicher, ob es eine endgültige Quelle gibt, aber so ziemlich jeder Artikel oder Beitrag, den ich über Paprika gelesen habe, scheint diese Definition zu teilen.http://security.stackexchange.com/q/3272/29865 http://stackoverflow.com/q/16891729/1157054 https://blog.filippo.io/salt-and-pepper/ Und außerdem nicht speichernDer Pfeffer wäre ziemlich nutzlos - es wäre im Grunde nur eine wirklich hackige Art, den Arbeitsfaktor Ihrer Hash-Funktion zu erhöhen.
Verweise auf die Definition des Wortes "Pfeffer" werden auf crypto.SE diskutiert: [Gibt es eine maßgebliche Definition des kryptografischen Begriffs "Pfeffer"?] (Https://crypto.stackexchange.com/q/24698/23581), [Definition von "Pfeffer" in Hash-Funktionen] (https://crypto.stackexchange.com/q/20578/23581).Ich schätze die Antwort in letzterem, wo der Pfeffer meistens als zusätzliches Geheimnis definiert wird, das dem Angreifer unbekannt ist, und es wäre eigentlich egal, ob dieses Geheimnis fest codiert / kakuliert / etc.solange es dem Angreifer unbekannt bleibt.
@Ajedi32, Als ich diese Frage stellte, war der Begriff "Pfeffer" überhaupt nicht weit verbreitet, aber ich habe den Begriff nicht erfunden, ich habe ihn einige Jahre zuvor irgendwo in Papierform gelesen.
Ich dachte, ein Pfeffer sei ein Salz pro Anwendung, das außerhalb der Datenbank gespeichert ist.
Eine interessante Sache für Paprika ist, dass das Testen der Werte für eine Paprika parallel durchgeführt werden kann, aber das Anwenden weiterer Runden eines Hashs muss nacheinander erfolgen.
sollte auch scrypt (https://en.wikipedia.org/wiki/Scrypt) als vernünftige Alternative erwähnen.
* "Es mag sich lohnen, es zu verwenden, aber der zusätzliche Nutzen überwiegt oft die Leistungskosten." * Ist das Wort ** "aber" ** ein Tippfehler in diesem Satz, oder verstehe ich etwas falsch?Es scheint, es sollte "weil" sagen.
#3
+21
Bryan Field
2016-07-15 18:37:58 UTC
view on stackexchange narkive permalink

Hintergrund: Sie sollten einen langsamen Kennwort-Hash verwenden. (d. h. bcrypt) Mit "langsam" meine ich rechenintensiv und benötige mehr als 100 ms (auf Ihrer Hardware) mit DoS-Schutz * sup>, um ein einzelnes Kennwort zu testen. Dies dient dazu, die Verarbeitungsleistung zu erhöhen, die (auf Angreifer-Hardware) erforderlich ist, um das Kennwort mit brutaler Gewalt zu finden, falls der Hash gestohlen wird. (im Fall von bcrypt wird es automatisch generiert) Salz sollte sehr einzigartig sein (d. h. lange & zufällig), aber nicht geheim . Die Verwendung eines eindeutigen Salzes bedeutet, dass ein Angreifer für jeden Benutzer einen separaten Brute-Force-Job ausführen muss.

Wenn kein Salz vorhanden wäre, könnte der Angreifer sofort einen verwenden Rainbow Table und überhaupt keine Brute Force.

Wenn Sie nur ein "gemeinsames Salz" verwenden, kann ein Angreifer Kennwörter für alle Benutzer mit einem einzelnen Brute knacken Job erzwingen. (nicht so schnell wie ein Regenbogentisch, aber immer noch viel einfacher als ein separater Brute-Force-Job für jeden)


Antwort: Wenn Sie den nicht speichern möchten Salz ("Brute Force the Hash zur Laufzeit", wie Ihr Professor vorschlägt)

  • Die möglichen Salze müssten sehr wenige sein.
  • Der Hash müsste ziemlich viel sein schneller

Dies würde den Zweck von Salz völlig zunichte machen und den Vorteil eines langsamen Hashs erheblich beeinträchtigen. Das ist ein schwerwiegender Konstruktionsfehler Ihres Professors. Grundsätzlich führt er sein eigenes Passwortspeicherschema durch, bei dem er den gut überprüften bcrypt -Algorithmus (oder scrypt oder PBKDF2 verwenden sollte) wie es verwendet werden sollte .


* Wie @Navin kommentierte, wäre dies ein potenzieller DoS-Angriffsvektor. Eine Lösung besteht darin, die Anzahl der stündlichen Versuche pro IP und pro Benutzername zu begrenzen. Es ist auch möglich, dass Sie die "Langsamkeit" Ihres Hash auf nur 10 ms reduzieren. Dies ist aus der Perspektive eines "gestohlenen Hash" nicht annähernd so gut wie 100 ms, aber immer noch viel besser als "Mikrosekunden". Sub>

"Wenn es kein Salt gäbe, könnte der Angreifer den Hash für alle Benutzer in einem einzigen Brute-Force-Job brutal erzwingen. (Spart auf diese Weise viel Zeit.", was dem Passwort "Passwort" entspricht.Dies ist auch eine Möglichkeit, Benutzer vor sich selbst zu schützen.
Verwenden Sie niemals MD5 zum Speichern von Passwörtern!Verwenden Sie stattdessen einen langsamen Hash.Aber ja, ich verstehe deinen Standpunkt.Ich habe die Antwort auf die Referenzregenbogentabellen aktualisiert, auf die Sie sich beziehen.
Wahr.In der realen Welt sollten Sie eine geeignete Passwort-Hashing-Bibliothek in der Sprache verwenden, mit der Sie arbeiten. Diese enthält normalerweise das Salz in der Hash-Zeichenfolge und schützt vor Timing-Angriffen, wodurch die gesamte Diskussion in Frage gestellt wird.Aber ja, MD5 ist nicht für Passwörter.
#4
+16
Steve Sether
2016-07-15 18:37:46 UTC
view on stackexchange narkive permalink

Ihr Professor ist nicht korrekt. Der Sinn eines Salt besteht darin, die Entropie der Hash-Passwörter zu erhöhen, um jegliche Art von Vorberechnungsangriff auf sie zu verhindern und zu verhindern, dass dasselbe Passwort von verschiedenen Benutzern denselben Hash-Wert hat.

Wenn Sie alle möglichen Salzwerte ausprobieren können, müssen Sie eine sehr geringe Entropie im Salz haben, was bedeutet, dass eine Vorberechnung über Regenbogentabellen möglich ist.

#5
+3
Cort Ammon
2016-07-16 03:07:46 UTC
view on stackexchange narkive permalink

Sie könnten das Salz auf diese Weise verwenden. Es wäre eine Art Hash-Stretching-Prozess. Normalerweise dehnen Sie einen Hash, indem Sie den Algorithmus mehrere tausend Mal wiederholen, wodurch Angreifer und Benutzer um das 1000-fache verlangsamt werden. In der Regel stört die Verlangsamung jedoch die Benutzer nicht. Die Verwendung eines Salzes auf diese Weise hätte den Effekt, dass ein Hash-Stretching-Algorithmus ausgeführt wird, indem er für viele unbekannte Hashes wiederholt werden muss.

Dies ist jedoch ein äußerst ungewöhnlicher Ansatz. Die traditionellen Methoden zum Salzen machen das, was Salze tun sollen, weitaus besser (machen Sie es so, dass niemand eine Passworttabelle vorberechnen kann). Die traditionellen Methoden zum Hash-Stretching machen das, was das Hash-Stretching tun soll, weitaus besser (machen Sie es so, dass Angreifer länger brauchen, um Passwörter zu berechnen). Auf diese Weise ein Salz zu verwenden, bedeutet, die beiden zusammen zu mischen. Das Ergebnis funktioniert irgendwie, aber die saubereren Ansätze machen beide Lösungen weitaus besser als das hässliche Missverständnis der Techniken.

#6
+2
supercat
2016-07-15 20:52:19 UTC
view on stackexchange narkive permalink

Anstatt an Salz als Brute-Forcing zu denken, denke ich gerne daran, dass es unmöglich ist, etwas über ein Passwort zu sagen, einschließlich seiner Beziehung zu anderen Passwörtern, indem man es betrachtet. Wenn das System kein Salting verwendet, zeigt ein Blick auf die Hash-Passwörter von zwei Benutzern an, ob ihre tatsächlichen Passwörter übereinstimmen. Wenn ein System nur mit dem Benutzernamen gesalzen wird, aber nichts Zufälliges, Zeitspezifisches oder Systemspezifisches, würde ein Blick auf die Hash-Passwörter eines Benutzers auf zwei Computern, die denselben Ansatz verwenden, anzeigen, ob die Passwörter des Benutzers auf den beiden Computern übereinstimmen. Wenn das System anhand der System-ID und des Benutzernamens gesalzen wird, jedoch nicht zufällig oder zeitspezifisch, kann jemand mit Zugriff auf zwei verschiedene Kennwort-Hashes desselben Benutzers feststellen, ob die zugeordneten Kennwörter übereinstimmen.

Die Auswirkung von Durch zufälliges Salting wird sichergestellt, dass keine zwei Hashes mit demselben Kennwort übereinstimmen, selbst wenn sie denselben Benutzer auf demselben System betreffen. Während man einen ähnlichen Effekt erzielen könnte, ohne die Salze zu speichern, wenn Anmeldeversuche sie brutal erzwingen würden, würde ein solcher Ansatz die praktische Länge des Salzes begrenzen, das man verwenden könnte, und somit die Wahrscheinlichkeit erhöhen, dass Passwörter, die in zwei Kontexten verwendet werden, die gleiches Salz und somit als passend erkennbar sein.

#7
+1
Jason Goemaat
2016-07-18 07:24:21 UTC
view on stackexchange narkive permalink

Was gibt Ihnen das Salzen? Angreifer haben vorberechnete Datenbanken mit Hash-Werten für Kennwörter, häufig und nicht. Wenn sie Ihre Datenbank erfassen und den Hash der Passwörter für jeden Benutzer haben, ist es einfach, ihre Hashes mit diesen Werten ohne Salz zu vergleichen.

Mit einem zufälligen Salz, das zusammen mit dem Passwort gespeichert wird, ist dies wahnsinnig schnelle Methode ist nicht mehr möglich. Wenn der Angreifer jedoch sowohl das Salz als auch den Hash hat, ist es weiterhin möglich, Wörterbuchangriffe für schwache Passwörter oder Brute-Forcing für kurze Passwörter zu verwenden. Alles, was der Angreifer tun muss, ist, das Salz zu verwenden und verschiedene Passwörter mit einem Wörterbuch oder einem Brute-Force-Angriff auszuprobieren.

Nehmen wir nun an, wenn das Passwort geändert wird, hashen Sie es mit einem zufälligen 12-Bit-Wert, der nicht ist nicht zusammen mit dem Salz gespeichert, das ist. Jedes Mal, wenn Sie das Passwort überprüfen, müssen Sie alle 4096-Werte ausprobieren. Auf meinem Computer dauert dies ungefähr 3,5 ms, sodass 284 Passwörter pro Sekunde überprüft werden können. Etwas mehr CPU-Auslastung auf dem Server, wenn sich jemand anmeldet, aber für jemanden, der Wörterbuch- oder Brute-Force-Angriffe versucht, haben Sie die Arbeit nur erheblich erschwert, selbst wenn er über Hash und Salt verfügt.

Würden Sie ihre Arbeit nicht viel einfacher machen, wenn sie nicht den Hasch und das Salz hätten?Seitdem überprüft der Server 4096 Werte, wenn ich nur einen sende, was viel mehr Fehlalarme ergibt.Dies war die Begründung, die mein Professor verwendet hat, aber sie scheint mir nicht sehr nützlich zu sein. Daher würde ich gerne jemanden sehen, der diesen Ansatz tatsächlich in realem Code verwendet.
Wenn sie den Hash nicht haben, hat es keinen Sinn, oder?Das Salzen schützt vor Menschen, die die Hashes haben.Wenn die Verwendung einer 12-Bit-Nummer populär wird, können Angreifer Datenbanken mit vorberechneten Hashes für jede dieser Nummern und allgemeinen / ungewöhnlichen Kennwörtern erstellen, um ihre Arbeit zu erleichtern.Selbst wenn Sie 4096 zufällige Salze erzeugen und diese anstelle einer einfachen 12-Bit-Zahl wiederverwenden, können sie sich beispielsweise auf einen Salzwert konzentrieren und möglicherweise viele Benutzer gefährden, wenn Sie Millionen haben.
Ja, das Salzen schützt vor Menschen, die die Hashes haben.Normalerweise macht es Sie nicht * anfälliger * gegenüber Leuten, die nicht über die Hashes verfügen, aber mit dieser Variante.
Wie macht es dich * verletzlicher *?
Denn wenn Sie ein Passwort an den Server senden, muss dieser mit allen 4096 möglichen Salzen überprüft werden, wodurch Sie ein viel höheres Potenzial für Fehlalarme haben.
Klingt so, als würden Sie von einer Kollision im Hashing-Algorithmus mit zufälligen Passwörtern sprechen.Wenn Sie einen 256-Bit-Hash haben, sind diese 4096 Versuche nahezu bedeutungslos, wenn Sie versuchen, eine Kollision zu erzeugen.Der Grund, warum Sie Brute Force anwenden können, wenn Sie den Hash haben, ist, dass Sie Millionen oder Milliarden von Schecks pro Sekunde auf Ihren lokalen Computern ausführen können.Wenn Ihre Site es Menschen ermöglicht, Millionen von Passwörtern zu versuchen, ohne sie zu sperren, (A) machen Sie es falsch und (B) sie müssen eine schnelle Verbindung zu Ihren Servern haben und (C) Sie sollten feststellen, dass die CPUs Ihres Servers vorhanden sindfixiert.
#8
  0
Kaz
2016-07-16 04:08:03 UTC
view on stackexchange narkive permalink

Die Idee, eine kontrollierte Anzahl von Bits des Salzes, das unabhängig konfiguriert und unabhängig von der Salzgröße ist, nicht zu speichern, scheint einen gewissen Wert zu haben.

Angenommen, wir haben 32-Bit-Salze. Wir könnten wählen, nur 22 Bits zu speichern und die restlichen 10 bei der Authentifizierung brutal zu erzwingen. Dies hat den Effekt, dass der Hashing-Funktion weitere Runden hinzugefügt wurden. Nicht so viele, dass die legitime Authentifizierung beeinträchtigt wird, aber genug, um die Schwierigkeit des Brute-Force-Crackings zu erhöhen.

Nächstes Jahr werden Maschinen schneller. Also durchsuchen wir die Passwortdatenbank und klopfen ein bisschen von jedem Salz ab: Jetzt speichern wir nur noch 21 Bits und müssen Brute Force durch 11. Braten

Es ist, als hätten wir die Hashing-Stärke verdoppelt, aber ohne die Unterbrechung des Ersetzens des Algorithmus und Aufforderung an die Benutzer, ihre Kennwörter erneut zu hashen (was der regulären Richtlinie zum Ablauf des Kennworts überlassen bleibt).

Dieser Ansatz des "progressiven Verwerfens von Salz" könnte die Nutzungsdauer von Hashing-Funktionen verlängern.

Diese Ansätze verlangsamen jedoch die legitime Authentifizierung und den Brute-Force-Angriff um den gleichen Faktor, sodass sie bestenfalls eine geringfügige Sicherheitsschicht bieten. Unser Fokus sollte auf Verbesserungen liegen, die der legitimen Verwendung nur eine konstante Menge an zusätzlicher Zeit hinzufügen und gleichzeitig die Schwierigkeit des Crackens vervielfachen. Eine Verbesserung, die diese Eigenschaft hat, erhöht natürlich die Entropie in der Passwortphrase! Jedes dem Passwort hinzugefügte Stück Entropie verursacht den legitimen Benutzern konstante Kosten, verdoppelt jedoch den Aufwand für das Brute-Force-Cracken. Ein Passwort der Länge N benötigt O (N) für Hash (und Typ), O (2 ** N) für Brute Force. Das Hinzufügen von 12 Bit Entropie zu einem Passwort schlägt das Verbergen von 12 Bit Salz.

"Dieser Ansatz des" progressiven Salzverwerfens "könnte die Nutzungsdauer von Hashing-Funktionen verlängern."Es gibt Hashing-Funktionen mit konfigurierbarer Hash-Größe (ein Beispiel ist Keccak), und diese als zugrunde liegendes Grundelement eines KDF zu verwenden, scheint mir eine viel bessere Idee zu sein.Sie können diese Technik weiterhin verwenden, um die Nutzungsdauer von nicht aktualisierten Kennwort-Hashes zu verlängern (bei einem Update hätte der neue Hash die zuletzt konfigurierte Hash-Größe), aber ob dies eine gute Idee ist, ist ebenfalls fraglich.Bei jeder Anmeldung wird das einfache Kennwort des Benutzers angezeigt (außer bei z. B. SRP), sodass Sie den Hash aktualisieren können.
@Rhymoid Sie benötigen eine Schreibberechtigung für den Kennwortdatenbankeintrag, um den Hash zur Authentifizierungszeit zu aktualisieren (wenn das Kennwort dem System kurz bekannt ist).Unter klassischem Unix konnte beispielsweise jeder "/ etc / passwd" lesen und die Hashes zur Authentifizierung verwenden, aber nur ein "setuid" -Dienstprogramm wie "/ bin / passwd" konnte sie aktualisieren.(Im Allgemeinen können wir uns ein System vorstellen, bei dem das Aktualisieren eines Authentifizierungsdatenbankeintrags ein von der Authentifizierung getrenntes Privileg darstellt, obwohl beide spezielle Berechtigungen sind, die nur bestimmten Programmen gewährt werden.)
#9
  0
coteyr
2016-07-21 18:54:13 UTC
view on stackexchange narkive permalink

In freier Wildbahn haben wir eine Benutzertabelle. Eine Benutzertabelle hat normalerweise die

  ID | Benutzername | Salz | encrypted_password | horridly_insecure_reset_key ======================================================== ========================= 1 | user1 | foo | 09b6d39aa22fcb8698687e1af09a3af9 | NULL2 | user2 | bar | 6c07c60f4b02c644ea1037575eb40005 | NULL3 | user3 | baz | 09b6d39aa22fcb8698687e1af09a3af9 | Zurücksetzen  

Dann sieht eine Authentifizierungsmethode wie folgt aus:

  def authenticate (Benutzer, Passwort) u = User.find (Benutzer: Benutzer) return u. encrypted_password == encrypt (password + u.salt) end  

Durch ein Salt pro Benutzer wird sichergestellt, dass Sie das Kennwort für user2 nicht herausfinden können, selbst wenn das Kennwort für Benutzer1 bekannt ist oder user3 ohne ihr Salz.

Sie stellen außerdem sicher, dass Sie das Salz nicht herausfinden können, indem Sie über eine Reihe verschlüsselter Kennwörter verfügen und einige verschlüsselte Kennwörter ausprobieren.

Im Wesentlichen auf diese Weise jeder Angriff gegen a Benutzer muss von vorne gestartet werden.

Selbst wenn ein Angreifer eine Liste von Benutzern und Salzen hat, muss er immer noch gegen jeden einzelnen Benutzer vorgehen, um festzustellen, ob ein Kennwort übereinstimmt. Wenn Sie einen Pool von Salzen oder ein statisches Salz hatten, könnte ich wissen, dass das Passwort von Benutzer1 ein Passwort ist, und dann einfach alle übereinstimmenden verschlüsselten Passwörter finden. Auf diese Weise werden sie zumindest ein wenig langsamer.

Wenn wir uns nun die Salze ansehen, wollen wir die Wiederverwendung von Salz reduzieren. Zwei identische Salze erleichtern den Angreifern. Wenn zwei Personen dasselbe Salt und dasselbe Passwort verwenden, wird der andere Benutzer beschädigt, wenn ein Benutzer beschädigt wird.

Nehmen wir also an, wir verwenden nur diese drei Salze. Und wir haben 3000 Benutzer. Das heißt, 1000 Menschen haben das gleiche Salz. Wenn 1% von ihnen ein Passwort von "Passwort" haben, können diese Personen alle gleichzeitig geknackt werden. 10 Accounts werden gleichzeitig gehackt. Weil wir die drei Salze kennen. Das ist eine sehr einfache Strecke, um 30 Leute gleichzeitig anzugreifen.

Nun, wenn jedes Salz einzigartig ist. Und wir wissen, dass das Passwort von Benutzer1 ein Passwort ist, das Ihnen nichts nützt. Sie haben immer noch nur 1 Benutzer geknackt. Für alle anderen 2999 Benutzer müssen Sie noch "Kennwort + Salt = verschlüsseltes Kennwort" ausführen.

Ein wirklich wichtiger Hinweis.

Sicherheit durch Dunkelheit ist keine Sicherheit. Das bedeutet nicht, dass Sie Ihre Benutzertabelle auf Google veröffentlichen sollten, da dies albern ist. Bei der Messung der Sicherheit sollten Sie jedoch davon ausgehen, dass der Angreifer über alles verfügt. Sie können nicht sagen: "Aber sie kennen das Anwendungssalz nicht, weil sie den Quellcode nicht haben." Weil sie konnten. Das bedeutet nicht, dass Sie Ihre Salze verschenken, es bedeutet nur, dass es keine echte Sicherheit ist. Angenommen, sie haben den Benutzernamen und das Salt und versuchen dann, es ihnen zu erschweren, das Passwort zu erhalten.

SUPER WICHTIGER HINWEIS

Die Der hier verwendete Code und die Tabelle sind für den tatsächlichen Gebrauch etwa 9.000 Mal zu einfach. Das Passwort ist nicht verschlüsselt, die Salze sind zu kurz, die Methode ist etwas zu simpel, kurz gesagt, so etwas in der Produktion zu tun, ist nichts, was als sicher angesehen werden sollte. Ich habe diese Sache dort einfach zum Zwecke der Demonstration ausgewählt, nicht weil sie sicher sind.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...