Das funktioniert normalerweise so:

Angenommen, Ihr Passwort lautet "Baseball". Ich könnte es einfach roh speichern, aber jeder, der meine Datenbank erhält, erhält das Passwort. Also mache ich stattdessen einen SHA1-Hash und erhalte Folgendes:

  $ echo -n Baseball | sha1suma2c901c8c6dea98958c219f6f2d038c44dc5d362  

Theoretisch ist es unmöglich, einen SHA1-Hash umzukehren. Wenn Sie jedoch eine Google-Suche nach genau dieser Zeichenfolge durchführen, haben Sie keine Probleme, das ursprüngliche Kennwort wiederherzustellen.

Wenn zwei Benutzer in der Datenbank dasselbe Kennwort haben, ist dies der Fall Sie werden den gleichen SHA1-Hash haben. Und wenn einer von ihnen einen Passworthinweis mit der Aufschrift hat, versuchen Sie es mit "Baseball" - nun weiß ich, wie beide Benutzerpasswörter lauten.

Bevor wir es hashen, stellen wir eine eindeutige Zeichenfolge voran. Kein Geheimnis , nur etwas Einzigartiges. Wie wäre es mit WquZ012C . Jetzt haben wir die Zeichenfolge WquZ012Cbaseball gehasht. Das stimmt damit überein:

c5e635ec235a51e89f6ed7d4857afe58663d54f5

Wenn Sie diese Zeichenfolge googeln, wird nichts angezeigt (außer vielleicht this Seite), also sind wir jetzt bei etwas. Und wenn person2 auch "Baseball" als Passwort verwendet, verwenden wir ein anderes Salz und erhalten einen anderen Hash.

Um Ihr Passwort zu testen, müssen Sie natürlich wissen, was das Salz ist. Also müssen wir das irgendwo aufbewahren. Die meisten Implementierungen setzen es genau dort mit dem Hash fest, normalerweise mit einem Trennzeichen. Versuchen Sie dies, wenn Sie openssl installiert haben:

  [tylerl ~] $ openssl passwd -1Password: baseballVerifying - Passwort: baseball $ 1 $ oaagVya9 $ NMvf1IyubxEYvrZTRSLgk0  

Dies gibt uns einen Hash unter Verwendung der Standardbibliothek crypt . Unser Hash ist also $ 1 $ oaagVya9 $ NMvf1IyubxEYvrZTRSLgk0 : Es sind tatsächlich 3 Abschnitte, die durch $ getrennt sind. Ich werde das Trennzeichen durch ein Leerzeichen ersetzen, um es visuell klarer zu machen:

  $ 1 $ oaagVya9 $ NMvf1IyubxEYvrZTRSLgk0 1 oaagVya9 NMvf1IyubxEYvrZTRSLgk0
 

Wenn ich den Prozess ausführe wieder bekomme ich einen ganz anderen Hash mit einem anderen Salz. In diesem Beispiel gibt es ungefähr 10 ^{14 sup> Möglichkeiten, dieses eine Kennwort zu speichern. Alle diese Angaben gelten für das Kennwort "Baseball":}

  $ 1 $ 9XsNo9.P $ kTPuyvrHqsJJuCci3zLwL. $ 1 $ nLEOCtx6 $ uSnz6PF8q3YuUhB3rLTC3 / ​​$ 1 $ / jZJXTF3 $ cq. U $ KR0jkhpeb1sz.UIqvfYOR.  

Wenn ich jedoch absichtlich das Salz spezifiziere, das ich überprüfen möchte, erhalte ich mein erwartetes Ergebnis zurück:

  [ tylerl ~] $ openssl passwd -1 -salt oaagVya9Password: baseballVerifying - Passwort: baseball $ 1 $ oaagVya9 $ NMvf1IyubxEYvrZTRSLgk0  

Und das ist der Test, den ich durchführe, um zu überprüfen, ob das Passwort korrekt ist. Suchen Sie den gespeicherten Hash für den Benutzer, suchen Sie das gespeicherte Salt, führen Sie denselben Hash mit gespeichertem Salt erneut aus und überprüfen Sie, ob das Ergebnis mit dem ursprünglichen Hash übereinstimmt.

Implementieren dieses selbst

Dieser Beitrag ist kein Implementierungsleitfaden. Salzen Sie Ihren MD5 nicht einfach und nennen Sie ihn gut. Das reicht im heutigen Risikoklima nicht aus. Sie möchten stattdessen einen iterativen -Prozess ausführen, der die Hash-Funktion tausende Male ausführt. Dies wurde an anderer Stelle viele Male erklärt, daher werde ich hier nicht auf das "Warum" eingehen.

Es gibt mehrere gut etablierte und vertrauenswürdige Optionen hierfür:

• Krypta : Die oben verwendete Funktion ist eine ältere Variante des in alle integrierten Unix-Kennwort-Hashing-Mechanismus crypt Unix / Linux-Betriebssysteme. Die ursprüngliche (DES-basierte) Version ist schrecklich unsicher; denke nicht einmal darüber nach. Das, was ich gezeigt habe (MD5-basiert), ist besser, sollte aber heute noch nicht verwendet werden. Spätere Variationen, einschließlich der SHA-256- und SHA-512-Variationen, sollten angemessen sein. Alle neueren Varianten implementieren mehrere Runden von Hashes.

• bcrypt : Die Blowfish-Version der Krypta oben genannter Funktionsaufruf. Profitiert von der Tatsache, dass Blowfish einen sehr teuren Schlüssel-Setup-Prozess hat und einen "Kosten" -Parameter verwendet, der die Schlüssel-Setup-Zeit entsprechend erhöht.

• PBKDF2 : ("Kennwortbasierte Schlüsselableitungsfunktion Version 2") Erstellt, um starke kryptografische Schlüssel aus einfachen Kennwörtern zu erstellen. Dies ist die einzige hier aufgeführte Funktion, die tatsächlich über einen RFC verfügt. Führt eine konfigurierbare Anzahl von Runden aus, wobei jede Runde das Passwort sowie das Ergebnis der vorherigen Runde enthält. Die erste Runde verwendet ein Salz. Es ist erwähnenswert, dass der ursprünglich beabsichtigte Zweck darin besteht, starke Schlüssel zu erstellen, nicht Passwörter zu speichern , aber die Überschneidung von Zielen macht dies auch hier zu einer vertrauenswürdigen Lösung. Wenn Sie keine Bibliotheken zur Verfügung hatten und gezwungen waren, etwas von Grund auf neu zu implementieren, ist dies die einfachste und am besten dokumentierte Option. Die Verwendung einer gut überprüften Bibliothek ist natürlich immer am besten.

• scrypt : Ein kürzlich eingeführtes System speziell schwierig auf dedizierter Hardware zu implementieren. Scrypt erfordert nicht nur mehrere Runden einer Hashing-Funktion, sondern verfügt auch über einen sehr großen Arbeitsspeicherstatus, um den RAM-Bedarf für Implementierungen zu erhöhen. Obwohl es sehr neu und größtenteils unbewiesen ist, sieht es mindestens so sicher aus wie die anderen und möglicherweise das sicherste von allen.

Technisch gesehen können Sie immer noch einen Regenbogentisch verwenden, um gesalzene Hashes anzugreifen. Aber nur technisch. Ein gesalzener Hash besiegt Regenbogentischangriffe, nicht durch Hinzufügen von Kryptomagie, sondern durch exponentielles Erhöhen der Größe des Regenbogentisches, der zum erfolgreichen Auffinden einer Kollision erforderlich ist.

Und ja, Sie müssen das Salz speichern :)

Es wird nicht nach dem Hash hinzugefügt. Es wird vor dem Hash hinzugefügt, sodass der Hash für jedes Salz völlig anders ist.

Es ist nicht

  Hash abcd = defgstore 123defg (für Benutzer mit 123 Salz) und 456defg (für Benutzer mit 456 Salz)  

Es ist

  Hash 123abcd = ghij Hash 456abcd = klmn  

Für Passwort-Hashes müssen Sie beispielsweise PBKDF2 / RFC2898 / PKCS5v2, Bcrypt oder Scrypt verwenden, mit denen Sie stattdessen eine Anzahl von Iterationen ("Arbeitsfaktor") auswählen können als nur einer. PBKDF2 verwendet beispielsweise intern HMAC -schlüssel mit einem bekannten Hash-Algorithmus (normalerweise SHA-512, SHA-256 oder SHA-1) für eine Reihe von Iterationen, vorzugsweise Zehntausende bis Hunderttausende So hoch wie möglich, ohne dass sich Benutzer beschweren.

Der Grund für die große Anzahl von Iterationen besteht darin, einen Angreifer zu verlangsamen, was wiederum den Schlüsselbereich verringert, den sie in einem bestimmten Zeitraum durchlaufen können Daher können sie die besseren Passwörter nicht effektiv angreifen. "Passwort" und "P @ $$ w0rd" werden natürlich unabhängig von einem Offline-Angriff geknackt.

Sie haben Recht, jede Zeile (Benutzer) benötigt ihr eigenes eindeutig erzeugtes, kryptografisch zufälliges langes Salz . Dieses Salz wird im Klartext gespeichert.

Mit PBKDF2, Bcrypt oder Scrypt würde ich auch empfehlen, die Anzahl der Iterationen (Arbeitsfaktor) in der Datenbank auch im Klartext zu speichern, damit sie leicht geändert werden können (ich persönlich verwende eine etwas zufällige Zahl von Iterationen - wenn es immer anders ist, dann gibt es weniger Angst vor "Oh nein, eine winzige Änderung könnte alles durcheinander bringen - NIEMALS WIEDER ÄNDERN" vom Management oder anderen Entwicklern)

Beachten Sie, dass bei Verwendung von PBKDF2 als Passwort Hashing, fordern Sie niemals eine größere Ausgabe als die native Hash-Ausgabe an - für SHA-1 sind das 20 Bytes und für SHA-512 64 Bytes.

Um tatsächliche Beispiele für PBKDF2 mit zwei verschiedenen Salzen zu nennen :

(PBKDF2 HMAC Passwort Salz Iterationen outputbytes Ergebnisse)

• PBKDF2 HMAC-SHA-512 mypass vA8u3v4qzCdb 131072 64
  • 2e3259bece6992f012966cbf5803103fdea7957ac20f3ec305d62994a3f4f088f26cc3889053fb59a4e3c282f55e9179695609ee1147cffae1455880993ef874
• PBKDF2 HMAC-SHA-512 MyPass l6eZQVf7J65S 131072 64
  • 1018ad648096f7814bc2786972eb4091f6c36761a8262183c24b0f4d34abb48073ed2541ee273220915638b46ec14dfb2b23ad64c4aa12f97158340bdc12fc57

Zusätzlich zu den Aussagen von Tylerl ist es wichtig zu betonen, dass in der modernen Krypto Salze nicht zum Schutz vor Regenbogentischen verwendet werden. Niemand benutzt wirklich Regenbogentische. Die wirkliche Gefahr ist die Parallelisierung:

• Wenn Sie kein Salz oder nur ein statisches Salz haben und ich Ihre DB mit einer Million Hashes stehle, kann ich alle meine werfen Kerne beim Bruteforcen, und jeder Kern greift gleichzeitig eine Million Hashes an, da jedes Mal, wenn ich eine der als Passwörter verwendeten Zeichenfolgen drücke, eine Hash-Übereinstimmung angezeigt wird. Daher muss ich den Suchraum einmal ausschöpfen, um eine Million Passwörter zu knacken. Das ist eine völlig realistische Skala von Passwortlecks und ein attraktives Ziel, um ein paar Dutzend GPUs auf oder sogar ein benutzerdefiniertes FPGA zu werfen. Selbst wenn ich nur die unteren 30% des Suchraums erschöpfe, werde ich immer noch mit 500.000 realen Passwörtern oder so davonkommen. Diese Passwörter werden dann zum Aufbau meines Wörterbuchs verwendet. Wenn also das nächste Mal jemand eine Hash-Datenbank verliert, werden 90% davon in Stunden geknackt.
• Wenn stattdessen jedes Passwort mit einem eigenen Passwort gehasht wird , einzigartiges Salz, dann muss ich jeden einzelnen einzeln angreifen, da selbst bei identischen Passwörtern völlig unterschiedliche Hashes gespeichert sind. Das bedeutet, dass ich vielleicht meine teure, stromhungrige GPU / FPGA-Farm verwenden könnte, um die paar hochwertigen Ziele anzugreifen (sagen wir, wenn Obama Ihr Benutzer wäre, würde das Erhalten seines Passworts immer noch die Kosten rechtfertigen), aber ich werde es nicht bekommen mehrere hunderttausend Passwörter kostenlos davon. Wenn ich die gesamten Millionen Passwörter erhalten wollte, musste ich eine Million Mal eine vollständige Brute-Force-Suche durchführen.

Und deshalb schützt Sie jedes Salz, ob statisch oder nicht, vor vorbereiteten Regenbogentischen, solange es nicht weit verbreitet ist, aber nur einzigartige Per-Hash-Salze schützen Sie vor der realen Gefahr, mit viel paralleler Rechenleistung alles zu knacken sofort.

Es ist sicherer, da mehrere Personen, die dasselbe Kennwort haben, unterschiedliche Hashs haben.

Einfache Implementierung mit Python:

  hashlibpasswordA = '123456'passwordB =' importieren 123456'hashlib.md5 (PasswortA) .hexdigest () 'e10adc3949ba59abbe56e057f20f883e'hashlib.md5 (PasswortB) .hexdigest ()' e10adc3949ba59abbe56e057f20f883e ' 

Erstens, wenn zwei Benutzer das eher schwache Passwort "Baseball" verwenden, hilft das Knacken eines Passworts überhaupt nicht, das zweite Passwort zu knacken, weil es gesalzen ist. Ohne zu salzen, haben Sie zwei Passwörter zum Preis von einem geknackt.

Zweitens enthalten Regenbogentabellen vorberechnete Hashes. So könnte ein Cracker den Hash von "Baseball" in einem Regenbogentisch mit einer Unmenge von Einträgen nachschlagen. Viel schneller als die Berechnung der Millionen Hashes in der Regenbogentabelle. Und das wird durch Salzen verhindert.

Und jetzt eine wichtige: Einige Leute haben gute Passwörter, andere schlechte Passwörter. Wenn Sie eine Million Benutzer haben und drei das identische Passwort verwenden, wissen Sie nur, dass das Passwort schwach ist. Ohne Salz haben Sie drei identische Hashes. Wenn also jemand Ihre Datenbank mit Hashes stiehlt, kann er sofort erkennen, welche Benutzer schwache Passwörter haben, und sich darauf konzentrieren, diese zu knacken. Viel einfacher, "Baseball" zu knacken als 1keOj29fa0romn. Ohne zu salzen fallen die schwachen Passwörter auf. Beim Salzen hat der Cracker keine Ahnung, welche Passwörter schwach und welche schwer zu knacken sind.

Ob der Hash gesalzen ist oder nicht, macht nur dann einen Unterschied, wenn der Angreifer den Passwort-Hash hat. Ohne Salz kann der Hash mit einer Regenbogentabelle angegriffen werden: einem vorberechneten Wörterbuch, das Passwörter mit Hashes verknüpft. Ein N-Bit-Salz erhöht den Speicherbedarf für eine Regenbogentabelle und die Zeit für die Berechnung dieser Tabelle um den Faktor 2 ** N. So erfordert beispielsweise mit einem 32-Bit-Salt nur ein einziger Eintrag im Wörterbuch der Regenbogentabelle, beispielsweise für das Kennwort passw0rd , viele Gigabyte Speicherplatz, was eine solche Regenbogentabelle mit der aktuellen Speicherhardware sehr teuer macht. Wenn also ein Salt vorhanden ist, wird der Angreifer auf einen Brute-Force-Angriff auf die spezifischen Kennwort-Hashes reduziert, die erhalten wurden.

Allerdings:

• für schwache Kennwörter Ein Brute-Force-Angriff wird in relativ kurzer Zeit erfolgreich sein.
• In einer Regenbogentabelle werden keine ausreichend starken Passwörter gefunden.
• Wenn der Angreifer Zugriff auf die Hashes hat, hat die Systemsicherheit wurde bereits kompromittiert: Moderne Systeme und Protokolle enthüllen ihre Passwort-Hashes nicht. Wenn der Angreifer keinen Zugriff auf die Kennwortdatenbank erhalten kann, können die Kennwörter auch im Klartext gespeichert werden.
• Wenn ein Angreifer das System kompromittieren muss, um zu den Hashes zu gelangen Um Kennwörter von ihnen umzukehren, sind die einzigen Kennwörter, die für den Angreifer von Wert sind, diejenigen, die für andere Sicherheitsdomänen wiederverwendet werden, auf die der Angreifer noch keinen Zugriff hat. Passwörter, die nicht wiederverwendet werden, haben keinen Wert (und sicherlich weniger Wert als andere vertrauliche Informationen, die mit den Konten verknüpft sind).

Angenommen, Benutzer joewestlake verwendet das Kennwort god1234 . Der Angreifer kehrt dies sofort mithilfe eines Regenbogentisches um. (Oder innerhalb weniger Minuten nach dem Knacken mit einem Brute-Force-Angriff, wenn der Hash gesalzen ist, da das Passwort so schlecht ist.) Das Problem ist nun, dass joewestlake auch god1234 code verwendet > für sein Google Mail-Konto und für Online-Banking, oops! Jetzt liest der Angreifer Joes E-Mails und lernt genug über Joe, damit er die Frage "Wie hieß Ihr erstes Haustier?" Leicht beantworten kann, wenn er sich bei Joes Online-Banking anmeldet.

Also, die Der Grund für Salze ist, dass sie Benutzer etwas schützen, indem sie das Umkehren von Passwörtern mittlerer Sicherheit erschweren: Passwörter, die ohne Salz vernünftigerweise in einer Regenbogentabelle zu finden sind, aber stark genug sind dass es sehr lange dauert, sie einzeln brutal zu zwingen. Salze bieten diesen Vorteil jedoch nur für den Fall, dass die Hashes kompromittiert werden, was bereits eine schwerwiegende Sicherheitsverletzung darstellt, und der Vorteil gilt nur für Benutzer, die ihre Kennwörter mit mittlerer Sicherheit in anderen Systemen wiederverwenden.

Angenommen, Joe hat stattdessen ein Passwort verwendet, das aus 10 zufälligen alphanumerischen Zeichen und Symbolen besteht. Dies könnte immer noch in einem Regenbogentisch sein, erfordert aber viel Arbeit. Selbst wenn Joe dasselbe Passwort für Google Mail und Online-Banking verwendet hat, ist er dank des Salzes sicher. Der Cracker lässt seinen Brute-Force-Crack vielleicht mehrere Stunden, vielleicht Tage lang laufen. Der Riss liefert zahlreiche schwache Passwörter von anderen Benutzern desselben Systems, die schwache Passwörter haben. Der Angreifer ist mit dieser Ausbeute zufrieden und hört auf zu knacken. Joes Passwort wird niemals rückgängig gemacht.

Wenn der Verstoß erkannt wird und Benutzern (einschließlich Joe) empfohlen wird, ihre Kennwörter zu ändern, hat Joe die Möglichkeit, den Cracking-Versuchen des Angreifers zu entkommen, selbst wenn der Angreifer weiterhin den gesamten Kennwortbereich mit mittlerer Sicherheit angreift enthält Joes Passwort. Joe weiß, dass das Kennwort, das er auf dem kompromittierten System verwendet hat, genau mit seinem Google Mail- und Bankkennwort übereinstimmt. Daher versucht er, die beiden anderen zu ändern. Das Salz hilft hier, weil es den Benutzern, die ein Passwort wiederverwenden, Zeit verschafft, ihr Passwort zu ändern. Das Salz hilft nicht denen mit sehr schwachen Passwörtern, die innerhalb von Minuten geknackt werden, aber Benutzer von Passwörtern, deren Knacken Stunden oder Tage dauert, haben eine Kampfchance.