Frage:
Salz oder nicht salzen?
marco-fiset
2012-07-20 17:45:06 UTC
view on stackexchange narkive permalink

Mögliches Duplikat:
Warum ist die Verwendung von Salt sicherer?
Warum hätte Salt LinkedIn-Passwörter nicht daran gehindert? geknackt werden?

Vor kurzem habe ich beschlossen, mehr über Web-Sicherheit zu erfahren, und bin an einem Punkt angelangt, an dem ich glaube, dass ich ziemlich gut verstehe, wie man sicher speichert Passwörter. Ich habe zufällige Salze zusammen mit Hashing für die Passwortspeicherung verwendet und bin ziemlich zuversichtlich in meine Lösung. Ich bin jedoch auf einen Artikel gestoßen, der mich sehr überrascht hat. Hier ein Zitat daraus:

Salze helfen Ihnen nicht

Es ist wichtig zu beachten, dass Salze zur Verhinderung von Wörterbuchangriffen oder Brute-Force-Angriffen strong unbrauchbar sind >. Sie können riesige Salze oder viele Salze oder handgeerntetes, schattengewachsenes Bio-Himalaya-Rosasalz verwenden. Es hat keinen Einfluss darauf, wie schnell ein Angreifer angesichts des Hashs und des Salzes aus Ihrer Datenbank ein Kandidatenpasswort versuchen kann.

Nun bin ich verwirrt ...

Ist das Hinzufügen von Salt zu Passwörtern immer noch relevant?

Interessante Lektüre: http://blogs.msdn.com/b/ericlippert/archive/2005/01/28/362587.aspx
Why would such points prevent salts from being relevant? The points in that article have applied to salts all along.
@StuperUser Ich habe gerade den ersten Teil gelesen und es sieht sehr vielversprechend aus! Danke für den Link.
What this guy is saying, is that wearing your seatbelt doesn't protect you against catching a cold. Certainly true, but not very useful information, and definitely not something that you should act on.
AilisxmgetCMTörgWMittag Ok so if I understand correctly, salts are still useful, but do not protect you against every type of attack?
Wenn dies in IT Security veröffentlicht wurde, kann ich sehen, dass es als Duplikat geschlossen wird. Ich bin jedoch weiterhin der Meinung, dass es für die Implementierung der kennwortbezogenen Sicherheit relevant ist, sodass es hier möglicherweise zum Thema gehört. Es hat bereits 3 enge Stimmen, wenn es noch eine bekommt, werde ich es schließen.
http://cooking.stackexchange.com/ ist ein besserer Ort, um solche Fragen zu stellen
@maple_shaft Das Problem mit Sicherheitsfragen auf dieser Website wird hier aufgezeigt: Die [am besten bewertete und akzeptierte Antwort] (http://programmers.stackexchange.com/a/157575) geht völlig daneben.
Ebenfalls von Interesse: [Warum hätte Salt nicht verhindert, dass LinkedIn-Passwörter geknackt werden?] (Http://security.stackexchange.com/q/15910)
Sieben antworten:
Kilian Foth
2012-07-20 17:54:54 UTC
view on stackexchange narkive permalink

Ja und Nein.

Salt schützt Sie vor jemandem, der Ihre Datenbank erhält und die tatsächlichen Passwörter ableitet, obwohl diese gehasht sind. (Wenn jemand Ihre gesamte Datenbank stiehlt, hat er wahrscheinlich auch die Benutzerdaten erhalten, die die Passwörter eigentlich schützen sollten. Nehmen wir jedoch an, dass Passwörter noch wertvoller sind als die Verwendung von Daten, da viele Benutzer ihre Passwörter verwenden Auf mehreren Websites, die dann ebenfalls gefährdet wären.) Daher ist sowohl Hashing als auch Salting Standard, um Ihre Benutzer optimal zu schützen.

Salt schützt Sie jedoch nicht vor Personen, die "password123" als auswählen Passwort und ein Angreifer, der einfach gängige Passwörter ausprobiert. Nichts kann Sie davor schützen - wenn der Benutzer sein lahmes Passwort eingeben und Zugriff erhalten kann, kann dies auch ein Angreifer tun (das System weiß nicht, wer sich am anderen Ende der Leitung befindet, was zunächst der gesamte Punkt der Passwörter ist ).

Für eine gute Sicherheit müssen sowohl der Anbieter als auch der Benutzer minimal kompetent handeln - einer der beiden reicht nicht aus.

+1 für "Wenn jemand Ihre gesamte Datenbank stiehlt, hat er wahrscheinlich auch die Benutzerdaten erhalten, die die Passwörter eigentlich schützen sollten", habe ich das nie so gesehen !!
@marco-fiset: Wenn Sie keine Bank sind, sind es wahrscheinlich nicht die Benutzerdaten, nach denen sie suchen. Es sind die Passwörter selbst. Hacker suchen nach Passwortlisten, weil sie wissen, dass viele Leute dasselbe Passwort für mehrere Websites verwenden. Wenn sie also Ihr Twitter-Passwort stehlen können, können sie möglicherweise auch in Ihr PayPal-Konto eindringen.
Salze * "hindern niemanden daran, das tatsächliche Passwort abzuleiten" *, sie machen es nur schwieriger, was immer gut ist. Eine andere gängige Praxis * (wenn auch nicht so häufig wie sie sein sollte) * aus demselben Grund ist die Verwendung eines sehr langsamen Hashing-Algorithmus wie [bcrypt] (http://en.wikipedia.org/wiki/Bcrypt). . Die Verwendung von bcrypt mit einem Salt pro Benutzer und einem Site-weiten Salt * (damit jemand, der Ihre Datenbank erhält, kein ** Passwort ** knacken kann, es sei denn, er hat auch Ihren Quellcode, der viel seltener vorkommt) * über das Beste, was Sie tun können, wenn es um die Speicherung von Passwörtern geht.
Ein Salt allein verhindert nicht, dass jemand das Passwort aus dem Hash erhält, sondern verhindert nur die Verwendung von Regenbogentabellen. Wenn Sie einen schnellen Hash wie md5 oder sogar SHA-512 verwenden, kann ein Angreifer mithilfe von GPUs auch einigermaßen sichere Passwörter brutal erzwingen. Sie müssen einen langsamen Hash verwenden, der für diesen Zweck entwickelt wurde, wie PBKDF2, bcrypt oder scrypt.
Ich verwende bereits bcrypt, da es der am meisten akzeptierte Algorithmus für das Passwort-Hashing zu sein scheint.
Denken Sie daran, dass Sie einen nicht öffentlichen Wert für ein Salz verwenden sollten, wie ich [hier] beschreibe (http://security.stackexchange.com/questions/17421/how-to-store-salt/17435#17435). Das Salz sollte nicht öffentlicher sein als der Passwort-Hash. Wenn das Salz verfügbar ist, sind Sie anfällig für Angriffe mit Einzelsalz-Regenbogentabellen, die Ihnen keine Zeit geben, auf einen Verstoß zu reagieren.
Pieter B
2012-07-20 17:50:05 UTC
view on stackexchange narkive permalink

Salz ist nicht da, um diese zu verhindern. Salze sollen Angriffe verhindern, indem sie Regenbogentabellen verwenden, bei denen es sich im Grunde um Listen von Hashes und deren Passwörtern handelt. Dies ist der Fall, wenn ein Angriff bereits Ihren Passwort-Hash hat.

Brian
2012-07-20 17:52:21 UTC
view on stackexchange narkive permalink

Zusätzlich zu den Regenbogentabellen verhindern Salze, dass jemand mit Zugriff auf Ihre Datenbank weiß, ob ein bestimmtes Benutzerpaar dasselbe Kennwort verwendet.

Dean
2012-07-20 23:58:15 UTC
view on stackexchange narkive permalink

Salze verhindern nicht, dass jemand ein bestimmtes Passwort knackt. Sie verhindern, dass jemand mithilfe einer Regenbogentabelle viele Kennwörter gleichzeitig knackt.

Angenommen, Sie haben die folgenden Benutzer auf Ihrer Website (das Kennwort würde nicht in der Datenbank gespeichert, sondern nur die Hash-Version). 

  USER PASSWORD HASHED PASSWORD ==================================== ==== hamfist god de898928393a893bttltoad god de898928393a893woob god de898928393a893marco-fiset mypass1 1238ffff2342399dean password2 a44ca77446ff449

(eine Regenbogentabelle) Dann wäre es für sie trivial zu prüfen, ob de898928393a893 in der Passwortliste vorhanden ist. Sie würden dann wissen, dass auf alle diese Benutzerkonten mit dem Kennwort god zugegriffen werden kann. In sehr kurzer Zeit hätten sie Zugriff auf die Konten aller Personen mit einem einfachen Passwort, das in ihrer Regenbogentabelle vorhanden ist (und an jeder anderen Stelle im Web, an der diese Person dieselbe E-Mail- / Passwort-Kombination verwendet).

Jetzt Wenn Sie ein zufälliges Salt hinzufügen, erhält jeder mit demselben Passwort unterschiedliche Hashes: 

  USER PASSWORD SALT HASHED PASSWORD ================ =============================== hamfist god ae # o abf4388ff343401bttltoad god cdo @ 29292d919100001woob god! password2 TEe9 b44ca7743324234

Jetzt hilft eine Regenbogentabelle nicht wirklich. Anstatt beispielsweise nur den Hash für god zu benötigen, müssen Sie den Hash für god + <all_potential_salts> vorberechnen. Art begrenzt, was Sie im Speicher speichern können.

Wenn jedoch jemand hamfist speziell erhalten möchte, hat er das Salz, da es in der Datenbank gespeichert ist, sodass dies einen Cracking-Versuch überhaupt nicht verlangsamt.

Brendan Long
2012-07-20 21:09:01 UTC
view on stackexchange narkive permalink

Es gibt einen weiteren Abschnitt des Artikels, der Ihre Frage beantwortet:

Sie sagten, Salze seien nicht hilfreich, aber was ist mit Regenbogentabellen? Warum würden Sie vorschlagen, dass Menschen keine Salze verwenden?

Wie im Artikel Provos & Mazières beschrieben, sind in bcrypt Salze eingebaut, um Angriffe auf den Regenbogentisch zu verhindern. Ich sage also nicht, dass Salze zwecklos sind, sondern dass sie Wörterbuch- oder Brute-Force-Angriffe nicht verhindern (was sie nicht tun). [Hervorhebung hinzugefügt]

Serra South
2012-07-20 19:13:15 UTC
view on stackexchange narkive permalink

Wie die anderen sagten, schützen sie Sie nur vor Regenbogentabellen und unterscheiden möglicherweise dieselben Passwort-Hashes zwischen verschiedenen Sites. Sie sollten keine Anstrengungen unternehmen, um Salz geheim zu halten (viele befürworten fälschlicherweise, sie auf einen anderen Server usw. zu legen). Es wäre in Ordnung, Salz neben Passwort-Hashes zu behalten. Alle Ihre Bemühungen sollten sich darauf konzentrieren, den Speicherort der Passwort-Hashes zu sichern.

Das mache ich schon. Hier gibt es nichts Neues.
Simone Gianni
2012-07-20 18:21:47 UTC
view on stackexchange narkive permalink

Wenn ich es richtig verstanden habe, lautet das Zitat "Es hat keinen Einfluss darauf, wie schnell ein Angreifer ein Kandidatenkennwort versuchen kann, wenn der Hash und das Salz aus Ihrer Datenbank vorliegen", und "Salz aus Ihrer Datenbank" ist hier der Hauptteil

Wenn Sie das Salt in der Datenbank speichern und ein Angreifer Zugriff auf die Datenbanktabelle hat, in der er den Hash und das Salt findet, kann er diese Hashes mit dem Salt brutal angreifen, also mit oder Das Nichtverwenden eines Salzes ist dasselbe (mit Ausnahme der Verlangsamung des Angreifers aufgrund erhöhter Hashing-Arbeit, die ein Faktor ist, aber nicht so wichtig).

So gesehen ist es sinnvoll, wenn die Angreifer hat "Salze aus Ihrer Datenbank".

+1 but another recommended defense against brute force is to iterate through the hash many times eg. 1000 so the attacker has to also try multiple iterations for each attempt
Hallo James, ja, aber wenn Sie ein Passwort erhalten, müssen Sie es mit Ihren Datenbankeinträgen vergleichen, damit Sie alle Informationen, die erforderlich sind, um zu diesem Hash zu gelangen, in der Datenbank speichern, damit der Angreifer dieselben Informationen hat, wie er es getan hat schafft es, den ganzen Tisch zu bekommen. Sie können es für ihn (und für Sie) länger machen, dorthin zu gelangen, aber Informationen sind immer noch da. Selbst öffentliche / private Schlüsselpaare stellen immer noch nur eine große Rechenanforderung für diejenigen dar, die nicht über den privaten Schlüssel verfügen, aber zumindest in diesem Fall ist er stark asymmetrisch. Sie erreichen ihn in einer Sekunde, er in 2 Milliarden Jahren.
@james Das mehrmalige Durchlaufen der Hash-Funktion ist nicht so effektiv, wie es sich anhört. Sie erhalten immer noch einen Hash, der eine Schicht von * einem * Passwort entfernt ist. Sicher, es ist nicht in der Nähe des ursprünglichen Passworts, aber es wird immer noch etwas übereinstimmen. Dieses Problem wird durch die Verwendung eines starken Hashing-Algorithmus und der Verwendung eines langsamen Algorithmus erheblich gemildert.


ⓘ
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.
Lesen Sie weiter auf narkive:
Loading...