Frage:
Wird MD5 als unsicher angesehen?
Tawfik Khalifeh
2012-09-08 22:21:57 UTC
view on stackexchange narkive permalink

Nachdem all diese Artikel online über md5-Exploits verbreitet wurden, überlege ich, auf einen anderen Hash-Algorithmus umzusteigen. Soweit ich weiß, war es immer der Algorithmus der Wahl unter zahlreichen Datenbankadministratoren. Ist es ein großer Vorteil, MD5 anstelle von (SHA1, SHA256, SHA384, SHA512) zu verwenden, oder handelt es sich um ein reines Leistungsproblem?

Welchen anderen Hash empfehlen Sie (unter Berücksichtigung datengebundener Anwendungen) als Plattform)? Ich verwende derzeit gesalzene Hashes (gesalzene MD5-Hashes). Bitte berücksichtigen Sie sowohl MD5-Datei-Hashes als auch Passwort-Hashes.

Sie haben gesalzene Hashes erwähnt. Bedeutet das, dass Sie über Passwort-Hashing sprechen? Das Passwort-Hashing erfordert andere Eigenschaften als das normale Hashing, was SHA-256 in diesem Zusammenhang fast so schlecht macht wie MD5.
Ich verwende md5-Hash, um vor dem Laden die Integrität kritischer Dateien zu überprüfen, und gesalzene md5-Hashes für Kennwörter.
Beides ist keine gute Wahl, aber aus ganz anderen Gründen.
Wie viel Schlimmes, ich muss die Situation vollständig verstehen, bevor ich den ganzen Teil neu codiere. Es sind mindestens blutige 24 Stunden. Die Codebasis ist wie 2K
Sie möchten wahrscheinlich [So sichern Sie Passwörter sicher] lesen (http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords). Ich denke, es ist eine der wichtigsten Fragen auf dieser Seite.
Sieben antworten:
#1
+111
CodesInChaos
2012-09-09 00:10:16 UTC
view on stackexchange narkive permalink

MD5 für Passwörter

Die Verwendung von Salted MD5 für Passwörter ist eine schlechte Idee. Nicht wegen der kryptografischen Schwächen von MD5, sondern weil es schnell ist. Dies bedeutet, dass ein Angreifer Milliarden Kandidatenkennwörter pro Sekunde auf einer einzelnen GPU ausprobieren kann.

Sie sollten absichtlich langsame Hash-Konstruktionen wie Scrypt, Bcrypt und PBKDF2 verwenden. Einfach gesalzenes SHA-2 ist nicht gut genug, da es wie die meisten Allzweck-Hashes schnell ist. Weitere Informationen zu den zu verwendenden Kennwörtern finden Sie unter Wie werden Kennwörter sicher gehasht?.

MD5 für die Dateiintegrität

Die Verwendung von MD5 für die Dateiintegrität kann oder kann nicht ein praktisches Problem sein, abhängig von Ihrem genauen Nutzungsszenario.

Die Angriffe gegen MD5 sind Kollisionsangriffe, keine Pre-Image-Angriffe. Dies bedeutet, dass ein Angreifer zwei Dateien mit demselben Hash erstellen kann, wenn er die Kontrolle über beide hat. Aber er kann nicht mit dem Hash einer vorhandenen Datei übereinstimmen, die er nicht beeinflusst hat.

Ich weiß nicht, ob die Angriffe auf Ihre Anwendung zutreffen, aber ich persönlich würde mit der Migration beginnen, selbst wenn Sie es glauben nicht. Es ist viel zu leicht, etwas zu übersehen. Besser sicher als leid.

Die beste Lösung in diesem Zusammenhang ist derzeit SHA-2 (SHA-256). Sobald SHA-3 standardisiert ist, ist es auch eine gute Wahl.

Die Zahlen sind ziemlich beängstigend, [hashcat] (http://hashcat.net/hashcat/) kann bis zu [86,24M Kombination / s] auf 8 Threads versuchen, 7 64bit (md5 Hash) zu gewinnen, es ist wie eine neue Ära des Passworts auf freiem Fuß knacken. gute Antwort...
@sarepta-Hashcat ist harmlos im Vergleich zu ocl-Hashcat, das auf einer GPU ausgeführt wird. Eine einzelne GPU kann damit über 6 Milliarden Kombinationen pro Sekunde erreichen.
Ein Pre-Image-Angriff ist theoretisch gegen MD5 möglich, aktuelle Angriffe haben jedoch einen Rechenaufwand von 2 ^ 123,4 für ein vollständiges Pre-Image.
Beachten Sie, dass mit MD5 * teilweise * Pre-Image-Angriffe möglich sind. Sie können eine vorhandene Datei übernehmen und Metadaten ändern / Junk anhängen und eine Kollision mit einer Datei generieren, die Sie vollständig generieren. So funktioniert der Kollisionsangriff auf das MD5-SSL-Zertifikat.
@ewanm89 - 2 ^ 123.4 ist nicht realisierbar (selbst wenn Milliarden von GPUs Milliarden von MD5-Hashes pro Sekunde für Milliarden von Jahren berechnen). Ja, es ist um den Faktor 24 besser als 2 ^ 128, aber die Unterscheidung ist für echte Angriffe bedeutungslos. (Aber stimmen Sie anderen Gründen zu, um MD5 zu vermeiden).
@Polynomial Ich würde das nicht als partielles Vorbild bezeichnen. Es ist eher so etwas wie eine strukturierte Kollision.
@CodesInChaos Ja, das ist wahrscheinlich eine bessere Beschreibung. Es war ungefähr 7 Uhr morgens, als ich das schrieb!
@drjimbob Ich habe noch nicht gesagt, dass es machbar ist, obwohl wir dort ankommen, habe ich nur darauf hingewiesen, dass es existiert, und das war ein vollständiger Pre-Image-Angriff. Wie andere betont haben, ist ein teilweises Vorbild oft gut genug. Bei unserer derzeitigen Geschwindigkeit mit GPU- und FPGA-Hardware, die Bruteforce beschleunigt und immer schneller wird, wird es wahrscheinlich nicht lange dauern, bis ein vollständiges Pre-Image möglich ist.
@sarepta Meine GPU kann ~ 279,5 Millionen Kombinationen pro Sekunde für SHA1 verarbeiten und ist jetzt ein paar Jahre alt. Ich hasse es zu denken, was eine schöne, glänzende neue GPU für das schnellere MD5 tun kann ...
Mit GPUs erhalten Sie 33,1 Milliarden Hashes pro Sekunde für MD5. 6 Zeichen Passwörter werden sofort geröstet.
Die Autoren der Flame-Malware haben es geschafft, in MD5 eine Kollision mit ausgewählten Präfixen zu generieren, was ziemlich beängstigend ist. Ich würde diesen Algorithmus für keinen Zweck mehr empfehlen. SHA-3 ist mittlerweile AFAIK standardisiert.
@buherator Ich glaube nicht, dass SHA-3 noch standardisiert ist. Wir wissen, dass Keccak der Gewinner des Wettbewerbs ist, aber wir wissen nicht, welche Optimierungen NIST darauf anwenden wird, bevor es zu SHA-3 wird. In Bezug auf die Unsicherheit von MD5 ist nicht jede Anwendung auf Kollisionsfestigkeit angewiesen, sodass nicht jede Anwendung dringend von MD5 migrieren muss. Für neue Projekte würde ich MD5 sicherlich nicht empfehlen.
Ich habe diese Argumentation (über die Geschwindigkeit von md5) einige Male gesehen, und obwohl ich der Meinung bin, dass langsameres Hashing sicherer ist, verstehe ich die praktischen Ratschläge gegen das Salzen nicht.Also salze ich Saiten mit 20 Zeichen Salz, die resultierende Zeichenfolge ist mindestens 28 Zeichen.Jetzt kann ein Angreifer Milliarden von Hashes pro Sekunde und GPU ausführen. Nehmen wir an, er hat ein Jahr lang Millionen von GPUs im Einsatz.Wie groß ist die Chance, dass er die Originalsaite bekommt?Ich kann rechnen, die Wahrscheinlichkeit ist praktisch 0.
@ivan Ein Salt wird neben dem Passwort-Hash gespeichert und ist dem Angreifer somit bekannt.Passwort-Hashing ist nur die letzte Verteidigungsstufe, wenn ein Angreifer den Server mit all seinen Geheimnissen kompromittiert hat (einschließlich der Verschlüsselungsschlüssel, die zum Verschlüsseln des Passwort-Hash oder Pfeffers verwendet werden).
#2
+36
Thomas Pornin
2013-02-24 09:43:55 UTC
view on stackexchange narkive permalink

Um die Antwort von @CodesInChaos zu vervollständigen, wird MD5 häufig aufgrund der Tradition und nicht aufgrund der Leistung verwendet. Personen, die sich mit Datenbanken befassen, sind nicht dieselben Personen wie Personen, die sich mit Sicherheit befassen. Sie sehen oft kein Problem darin, schwache Algorithmen zu verwenden (siehe z. B. den Witz eines Algorithmus, den MySQL zum Hashing von Passwörtern verwendet hat). Sie verwenden MD5, weil sie MD5 verwendet haben und MD5 gewohnt sind.

Leistung wird viel häufiger diskutiert als gemessen. Und doch kann es logischerweise kein Leistungsproblem geben, wenn nichts zu messen ist. Mit einem Kern einer Basis-CPU können Sie mit MD5 mehr als 400 MByte pro Sekunde hashen, mit SHA-1 näher an 300 MB / s und mit SHA-256 an 150 MB / s. Auf der anderen Seite liefert eine anständige Festplatte Daten mit einer noch geringeren Rate (100 bis 120 MB / s wären typisch), sodass die Hash-Funktion kaum jemals der Engpass ist. Folglich gibt es keine Leistungsprobleme in Bezug auf das Hashing in Datenbanken.

Die üblichen Empfehlungen für Hash-Funktionen lauten:

  1. Tun Sie es nicht. Sie sollten keine elementaren kryptografischen Algorithmen verwenden, sondern Protokolle , die mehrere Algorithmen zusammenstellen, um gemeinsam einige Sicherheitsmerkmale bereitzustellen (z. B. vertrauliche und integrative Datenübertragung).

  2. Tu es wirklich nicht. Erstellen Sie zum Speichern von Passwörtern (genauer gesagt Token zur Passwortüberprüfung) keine benutzerdefinierte Mischung aus Hash-Funktion und Salzen. Verwenden Sie eine Konstruktion, die speziell für eine solche Verwendung untersucht wurde. Dies bedeutet normalerweise bcrypt oder PBKDF2.

  3. Wenn eine Hash-Funktion tatsächlich die Aufgabe erfüllt, verwenden Sie SHA-256. Erwägen Sie die Verwendung einer anderen Funktion nur, wenn ein ernstes Problem mit SHA-256 (höchstwahrscheinlich seine Leistung ) ordnungsgemäß erkannt und gemessen wurde.

  4. ol>
Ich sehe Ihre Antwort wie folgt: "Verwenden Sie Hash-Funktionen nicht direkt - verwenden Sie ein größeres System wie TLS für die Datenübertragung, Zertifikate für die Authentifizierung und / oder bcrypt oder PBKDF2 für die Kennwortspeicherung."
#3
+6
Bradley Kreider
2012-09-10 07:11:10 UTC
view on stackexchange narkive permalink

Ich verwende derzeit gesalzene Hashes (gesalzene MD5-Hashes).

Wenn Sie MD5-Hashes salzen, möchten Sie MD5 definitiv nicht verwenden. Es hört sich so an, als müssten Sie PBKDF2 oder bcrypt verwenden.

Soweit ich weiß, war es immer der Algorithmus der Wahl unter zahlreichen Datenbankadministratoren.

Das ist nicht der Fall ein zwingender Grund.

Ich habe mit vielen Datenbankadministratoren gearbeitet, die in der allgemeinen Technologie mindestens 5 Jahre hinterherhinken (ohne Versionskontrolle, unformatierte Perl-Skripte für alles usw.). Es waren vielleicht besonders schlechte Datenbankadministratoren, aber ich denke, das hängt mit der äußerst konservativen Denkweise zusammen, Dinge nicht zu ändern.

#4
+4
Machavity
2015-10-28 19:28:09 UTC
view on stackexchange narkive permalink

Um die bereits gegebenen Antworten zu ergänzen (von denen die meisten ausgezeichnet sind), haben wir jetzt ein Beispiel aus der Praxis, bei dem ein Datenverstoß (Ashley Madison) dazu geführt hat, dass die gesamte Kennworttabelle durchgesickert ist. Sie verwendeten bcrypt mit einem zufälligen Salz, um die Passwörter zu hashen. Ein Sicherheitsforscher beschloss, diese Hashes zu nehmen und sie brutal zu erzwingen. Dies war das Ergebnis

Infolgedessen stellt bcrypt aus mindestens zwei Gründen herkulische Anforderungen an jeden, der versucht, den Ashley Madison-Dump zu knacken. Erstens erfordern 4.096 Hashing-Iterationen eine enorme Menge an Rechenleistung. In Pierces Fall beschränkte bcrypt die Geschwindigkeit seines Cracking-Rigs mit vier GPUs auf dürftige 156 Vermutungen pro Sekunde. Zweitens, da bcrypt-Hashes gesalzen sind, muss sein Rig den Klartext jedes Hashs einzeln erraten und nicht alle im Einklang.

"Ja, das ist richtig, 156 Hashes pro Sekunde", schrieb Pierce. "Für jemanden, der es gewohnt ist, MD5-Passwörter zu knacken, sieht das ziemlich enttäuschend aus, aber es ist bcrypt, also nehme ich, was ich bekommen kann."

Pierce gab auf, als er die 4.000-Marke überschritten hatte. Um alle sechs Millionen Hashes in Pierces begrenztem Pool gegen die RockYou-Passwörter auszuführen, wären schätzungsweise 19.493 Jahre erforderlich gewesen, schätzte er. Mit insgesamt 36 Millionen gehashten Passwörtern im Ashley Madison-Dump hätte es 116.958 Jahre gedauert, bis der Auftrag abgeschlossen war.

Am Ende des Tages waren es die einzigen, die er knacken konnte waren lächerlich einfache oder gebräuchliche Passwörter (wie "123456").

Tatsächlich waren einige von ihnen als MD5-Hashes verfügbar (entweder von einem älteren System oder von etwas anderem, ich bin mir nicht sicher).Die waren kein Problem geknackt.
#5
  0
Matrix
2012-09-08 22:37:08 UTC
view on stackexchange narkive permalink

Ja, MD5 ist unsicher, ebenso wie SHA-1. Ich empfehle die Verwendung von SHA-256, wenn die Größe des Digests ein Problem darstellt. Denken Sie daran, wenn Sie es in einer BINARY-Spalte speichern, wird weniger Speicherplatz benötigt als in CHAR. Stellen Sie einfach sicher, dass es richtig gemacht wird. MD5 ist etwa 2,3x schneller als SHA-256. Weitere Benchmarks finden Sie unter http://www.cryptopp.com/benchmarks.html

Verwenden Sie keine Standard-Hashes für die Kennwortspeicherung. Sie sind viel zu schnell. PBKDF2 / bcrypt sind der richtige Weg.
#6
  0
Shane
2013-06-20 13:50:08 UTC
view on stackexchange narkive permalink

Um es kurz zu machen, es ist jetzt aufgrund von Regenbogentabellen ziemlich unsicher. Die Regenbogentabelle ist eine Liste von MD5-Hashes und ihren passenden Zeichenfolgen. Grundsätzlich würde ich andere Alternativen wie SHA1

in Betracht ziehen
Regenbogentabellen gelten fast gleichermaßen für alle ungesalzenen Hashes. Eine Migration zu SHA1 oder SHA2 würde fast nichts bewirken. Der richtige Ansatz für das Passwort-Hashing ist die Verwendung eines Salt zusammen mit einer absichtlich langsamen Passwort-Hashing-Funktion wie PBKDF2, bcrypt oder scrypt. Selbst mit schnellen ungesalzenen Hashes ist es oft billiger, eine neue GPU-Suche durchzuführen, als mit einer Regenbogentabelle.
#7
-1
Dom
2013-06-20 12:57:21 UTC
view on stackexchange narkive permalink


Sie sprechen alle über Unsicherheit, aber keiner von Ihnen hat die Frage direkt beantwortet.

Ich habe mit MD5 und Sha512 gearbeitet, die beide leicht zu knacken waren, sobald ich sie hatte hatte meinen kleinen Hacker-Experten darauf gesetzt, bis es uns beide wie ein Donner traf! Der einfachste und effektivste Weg, "Massenangriffe" wie die oben beschriebenen zu stoppen, besteht darin, einen Begrenzer für Login-Versuche festzulegen, was bedeutet:

  function checkbrute ($ user_id, $ mysqli) {// Zeitstempel der aktuellen Zeit abrufen $ now = time (); // Alle Anmeldeversuche wurden in den letzten 2 Stunden gezählt. $ valid_attempts = $ now - (2 * 60 * 60); if ($ stmt = $ mysqli->prepare ("SELECT time FROM login_attempts WHERE user_id =? AND time > '$ valid_attempts'")) {$ stmt->bind_param ('i', $ user_id); // Die vorbereitete Abfrage ausführen. $ stmt->execute (); $ stmt->store_result (); // Wenn mehr als 5 Anmeldungen fehlgeschlagen sind if ($ stmt->num_rows > 5) {return true; } else {return false; }}}  


Verstehst du meinen Punkt?
Die maximale Anzahl von Kombinationen, die der Hacker versuchen möchte, ist auf 5 Fehler pro 2 Stunden begrenzt. Sie können den Benutzer sogar nach X Versuchen blockieren.

Sie berücksichtigen nicht gestohlene / nicht ordnungsgemäß verworfene Sicherungen von Benutzerdatenbanken oder Benutzerdatensätzen, die durch einen Exploit (z. B. ein SQLi) massenhaft abgerufen wurden. Ihre Antwort bezieht sich auf das Hacken von Live-Datenbanken durch und durch die Serveranwendung, die als einzige auf solche Daten zugreifen soll, jeweils ein Benutzerkonto, das - wenn dies das einzige Risiko wäre - viel eleganter und mit einem Passwort gelöst werden könnte Hashes würden überhaupt nicht benötigt. Glaubst du mir nicht? Fragen Sie [LinkedIn] (http://www.zdnet.com/blog/btl/6-46-million-linkedin-passwords-leaked-online/79290) (unter vielen anderen);)
1) Ich habe ausdrücklich geschrieben, dass MD5 und SHA-2 als Passwort-Hashes nicht sicher sind. 2) Bei ordnungsgemäßer Verwendung sind keine Angriffe auf SHA-512 bekannt. Es ist ein kryptografischer Hash, kein Passwort-Hash. 3) Sie verpassen den Punkt der Passwort-Hashes. Der Zweck eines Kennwort-Hashs besteht darin, Kennwörter zu schützen, wenn Ihre Datenbank durchgesickert ist. In diesem Szenario hilft ein Ratenbegrenzer überhaupt nicht.
Die FWIW-Begrenzung von Anmeldeversuchen auf diese Weise macht es einfach, Denial-of-Service durchzuführen
@EricGrange: Natürlich beschränken Sie sie für jede IP oder was auch immer, nicht insgesamt.
@Evi1M4chine Im Zeitalter von IPv6 kann ein Angreifer einfach (und kostengünstig) Millionen verschiedener IPv6-Adressen haben


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...