Frage zu Password-Hashes (SHA512)

[Codehunter]

Hallo!

Bezieht sich eigentlich auf PHP, ist aber von allgemeiner Bedeutung, darum frag ich mal hier.

Da man ja MD5 nicht mehr verwenden soll, hashe ich Passwörter jetzt mit SHA512. Der String 'foo' plus Salt ergibt dann bei 5000 Runden z.B. folgenden Hash:

Code:

$6$rounds=5000$7IfaSuwiHawucad7$CiVrIv5dy15xaeiInz/IN2jRx82pqYU4yKy.lUtBeExzwsSRGPy8fjQiSN8lsjUjcIm08GzxSjJ.mj2z4qrN7/

Der Modus 6 (SHA512) und die 5000 Runden sind hardcoded.

Die Frage die ich mir stelle ist: Wenn der Modus 6 und die 5000 Runden ohnehin bekannt sind, sollte ich dann nicht lieber nur den eigentlichen Hash, also alles nach dem dritten "$" in der Datenbank speichern und später wieder hinzufügen beim Auswerten? Sonst gibt man doch im Fall eines Datenklaus unnötig Hinweise auf die Verschlüsselungsmethode. Oder mach ich jetzt einen Denkfehler?

Grüße
Cody

[Sir Rufo]

Irgendwo muss es ja bekannt sein und wenn es nicht in der Datenbank steht (was wurde benutzt) dann hast du ein Problem, wenn du das (was wird benutzt) änderst. Welches habe ich benutzt um diesen Hash zu erzeugen.

Das aktuelle (was wird benutzt) ist auch hinterlegt (im Skript, einer Config, ...) ... und damit auch potenziell gefährdet.

Ob du es nun in der Datenbank speicherst und damit auch wechseln kannst oder nicht bleibt vom Risiko also gleich.

[Codehunter]

Zitat:

Zitat von Sir Rufo (Beitrag 1291077)

Ob du es nun in der Datenbank speicherst und damit auch wechseln kannst oder nicht bleibt vom Risiko also gleich.

Prinzipiell stimme ich dir zu. Nur meiner Erfahrung nach sind die PHP-Scripte doch ein Stück weit sicherer als die Daten in einer Datenbank. Zumindest wenn man ein paar Grundregeln der Webserver-Konfiguration beachtet.

[mjustin]

Zitat:

Zitat von Codehunter (Beitrag 1291076)

Code:

$6$rounds=5000$7IfaSuwiHawucad7$CiVrIv5dy15xaeiInz/IN2jRx82pqYU4yKy.lUtBeExzwsSRGPy8fjQiSN8lsjUjcIm08GzxSjJ.mj2z4qrN7/

Fehlt in diesem String nicht das Salz? Der Salt-Wert soll ja zusammen mit dem entstandenen Hashwert in der Datenbank gespeichert werden (https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29)

[himitsu]

Was ist rounds=5000 ?

Heißt es, daß das Passwort 5000 Mal hintereinander eingerechnet wurde?

Bei 512 Bit, reichen knapp 80 Buchstaben (mit effektiven 6 Bit pro Buchstabe) doch schon aus, um einen sicheren eindeutigen Wert zu bekommen, denn mehr Informationen passen eh nicht rein. :gruebel:

[BUG]

Erst einmal: Das Salt sollte für jeden Hash unterschiedlich sein. Damit vermeidet man, dass ein Angreifer bei einer Wörterbuch-Attacke jedes Wort nur einmal Hashen muss und dann gegen die Datenbank vergleichen kann.

@himi: Die Runden erhöhen den Zeitaufwand des Angreifers.

Außerdem solltest du keine normale Hashfunktion verwenden, sondern eine Key-Derivation-Funktion wie bcrypt oder scrypt. Gründe findest du durch googeln genug :wink:

Wenn du dann mit einem zusätzlichem geheimen Salt oder einer zusätzlichen Verschlüsselung besser schlafen kannst, dann will ich dich nicht abhalten.

[Namenloser]

Ich denke, es ist in Ordnung, diese Informationen dort im Klartext stehen zu haben. In der Kryptographie geht man ja eigentlich immer davon aus, dass der Angreifer den Algorithmus kennt.

Was ich allerdings dennoch nicht schlecht finde, ist zwei verschiedene Salts zu kombinieren: Einen individuellen per Datensatz, der in der Datenbank gespeichert wird, und einen globalen, der irgendwo im Quelltext steht. Dann muss der Angreifer beide Systeme kompromittieren (oder mehr rechnen).

[Codehunter]

Zitat:

Zitat von mjustin (Beitrag 1291136)

Fehlt in diesem String nicht das Salz? Der Salt-Wert soll ja zusammen mit dem entstandenen Hashwert in der Datenbank gespeichert werden (https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29)

Ähm, nein, ist enthalten: $6$rounds=5000$7IfaSuwiHawucad7$CiVrIv5dy15xaeiInz/IN2jRx82pqYU4yKy.lUtBeExzwsSRGPy8fjQiSN8lsjUjcIm08 GzxSjJ.mj2z4qrN7/

Zitat:

Zitat von BUG (Beitrag 1291165)

Erst einmal: Das Salt sollte für jeden Hash unterschiedlich sein.

Danke für den Hinweis, hab ich entsprechend angepasst.

Zitat:

Zitat von Namenloser (Beitrag 1291176)

Was ich allerdings dennoch nicht schlecht finde, ist zwei verschiedene Salts zu kombinieren

Das würde allerdings nur gehen wenn ich mit der ganzen Hash-Prozedur zwei Durchläufe mache und den "User-Hash" im "System-Hash" unterbringe oder umgekehrt.

[Namenloser]

Zitat:

Zitat von Codehunter (Beitrag 1291504)

Zitat:

Zitat von Namenloser (Beitrag 1291176)

Was ich allerdings dennoch nicht schlecht finde, ist zwei verschiedene Salts zu kombinieren

Das würde allerdings nur gehen wenn ich mit der ganzen Hash-Prozedur zwei Durchläufe mache und den "User-Hash" im "System-Hash" unterbringe oder umgekehrt.

Versteh ich nicht ganz. Statt

Delphi-Quellcode:

hash(salt+password)

machst du einfach

Delphi-Quellcode:

hash(salt1+salt2+password)

.

[Codehunter]

Zitat:

Zitat von Namenloser (Beitrag 1291507)

Versteh ich nicht ganz. Statt

Delphi-Quellcode:

hash(salt+password)

machst du einfach

Delphi-Quellcode:

hash(salt1+salt2+password)

.

Das hat mit der Gegenprüfung zu tun. Wie gesagt, es dreht sich eigentlich um PHP und dort um die Funktion crypt().

Code:

//Verschlüsseln bzw. Hashen
$hash = crypt($plaintext_to_hash, $config_str_with_salt);

/Gegenprüfung
if ($hash == crypt($plaintext_to_check, $hash) {...}

Bei deiner Methode stünden wieder beide Salts im Klartext in der SQL-Datenbank, was du ja grade nicht wolltest. Denn der Hash muss den (Zufalls-)Salt enthalten, sonst wüsste das System beim späteren Vergleich ja nicht, welcher das war. Wenn einer der beiden Salts geheim sein soll, müsste man ihn vorher schon mal zum Hashen verwenden und das Ergebnis nochmal mit dem "öffentlichen" Salt.

[himitsu]

PHP-Quellcode:

//Verschlüsseln bzw. Hashen
$salt = random_irgendwas;
$hash = crypt($globalsalt . $plaintext_to_hash, concatsalt($config_str, $salt));

/Gegenprüfung
if ($hash == crypt($globalsalt . $plaintext_to_check, $hash) {...}

[Codehunter]

Sag ich doch... Nacheinander :-D

[Codehunter]

Wenn man sich eingehender mit der Materie befasst merkt man erstmal, wie leicht es ist da wirklich dumme Fehler einzubauen. Ich habe aber auch den Eindruck, es gibt wenig verständliche Anleitungen oder Tutorials dazu. Nicht konkret was PHP betrifft sondern ganz allgemein.

[BUG]

Ich finde die Artikel von Troy Hunt zu dem Thema Passwort/Authentifizierung ganz informativ:

• Our password hashing has no clothes
• Everything you ever wanted to know about building a secure password reset feature

[PeterPanino]

Zitat:

Zitat von Codehunter (Beitrag 1291076)

Da man ja MD5 nicht mehr verwenden soll

Wieso soll man MD5 nicht mehr verwenden? MD5 ist ein integraler Bestandteil vieler Anwendungen.

[Jumpy]

In diesem aktuelle Thread wird das auch aufgeführt:

http://www.delphipraxis.net/186647-s...nt-server.html

[BUG]

Zitat:

Zitat von Codehunter (Beitrag 1291076)

Da man ja MD5 nicht mehr verwenden soll

Our password hashing has no clothes tldr: "Normale" Hashes sind zu schnell und speichereffizient; und ermöglichen damit Brute-Force- und Wörterbuchattacken.

Abgesehen von Passwort-Hashing gibt es mittlerweile praktisch erfolgreiche Kollisionsattacken auf md5. Da das in Zukunft nicht besser wird, sollte man gleich einen heutigen Standard benutzen (SHA-2 oder SHA-3).

[PeterPanino]

Zitat:

Zitat von Jumpy (Beitrag 1316482)

In diesem aktuelle Thread wird das auch aufgeführt:

http://www.delphipraxis.net/186647-s...nt-server.html

Die Begründung in diesem Thread halte ich für Unsinn. Nur weil da steht "Das BSI sagt ...", heißt das nicht, dass man das auch glauben soll. Denn das ist eine viel zu allgemeine Aussage. Und wegen dem "Ashley-Madison-Hack" heißt das noch lange nicht, dass MD5 allgemein unsicher ist. Denn es kommt ja viel eher darauf an, wie man MD5 in ein übergreifendes Sicherheits-Konzept integriert. MD5 selbst ist ja nur ein Baustein - es wird wohl niemanden geben, der versucht, ein Haus mit einem einzigen Ziegelstein zu bauen.

Einfach allgemeinen Aussagen Glauben zu schenken halte ich für dumm.

[mkinzler]

Erster Pre-Image-Angriff 2004: https://de.wikipedia.org/wiki/Messag...st_Algorithm_5

Erster Kollisionsangriff 2008:
http://www.heise.de/security/artikel...D5-270106.html

Aber das ist ja erst 7 Jahre her ;)

[BUG]

Zitat:

Zitat von PeterPanino (Beitrag 1316490)

Die Begründung in diesem Thread halte ich für Unsinn. Nur weil da steht "Das BSI sagt ...", heißt das nicht, dass man das auch glauben soll.

Stimmt, das BSI ist nicht die letzte Autorität zu dem Thema; im Regelfall sind die eher zu gnädig bei Sicherheitssachen. Aber nicht nur das BSI warnt, eigentlich hört man das von allen Experten zu dem Thema.

Zitat:

Zitat von PeterPanino (Beitrag 1316490)

MD5 selbst ist ja nur ein Baustein - es wird wohl niemanden geben, der versucht, ein Haus mit einem einzigen Ziegelstein zu bauen.

Allerdings würde auch niemand bröckelige Ziegelsteine verbauen, wenn er genügend stabile Ziegelsteine hat.

[PeterPanino]

MD5 selbst ist ja nicht bröckelig. Bröckelig wird's erst, wenn du die Haustür und zugleich die Badezimmertür offenlässt und so jedermann deiner Frau beim Duschen zuschauen kann. ;-)

Was ich damit sagen möchte: Wenn du jemandem den Zugang zu deinen Passwort-Hashes erlaubst, bist du selbst schuld, wenn sie geknackt werden. Die Sollbruchstelle ist in diesem Fall ja wohl eher die offene Haustür in Kombination mit der offenen Badezimmertür ...

Übersetzt bedeutet das in diesem Fall, dass du deiner Frau nicht mehr erlaubst, sich zu duschen, nur weil du unfähig bist, die Türen richtig abzuschließen.

[BUG]

Zitat:

Zitat von PeterPanino (Beitrag 1316498)

MD5 selbst ist ja nicht bröckelig.

Doch, genau das. Es gibt praktisch ausführbare Kollisionsangriffe: md5 ist bröckelig!

Zitat:

Zitat von PeterPanino (Beitrag 1316498)

Bröckelig wird's erst, wenn du die Haustür und zugleich die Badezimmertür offenlässt und so jedermann deiner Frau beim Duschen zuschauen kann. [...] Wenn du jemandem den Zugang zu deinen Passwort-Hashes erlaubst, bist du selbst schuld, wenn sie geknackt werden. Die Sollbruchstelle ist in diesem Fall ja wohl eher die offene Haustür in Kombination mit der offenen Badezimmertür ...

Mit der Argumentation brauchst du deine Passwörter auch gar nicht zu hashen. Deine Server sind anfällig, deine Türen stehen offen, jeder weiß bereits wie deine Frau nackt aussieht ... ähem, so langsam läuft das mit den Metaphern aus dem Ruder :stupid: :mrgreen:

Im Ernst, das sichere Verwalten von Passwörtern ist die einzige Sicherheit, die du garantieren kannst. Die große Mehrheit aller (und damit auch deiner) Benutzer verwenden Passwörter mehrfach und das Mindeste was du tun kannst, ist dieses Sicherheits-Netz aufzuspannen.

[Sir Rufo]

Zitat:

Zitat von PeterPanino (Beitrag 1316498)

MD5 selbst ist ja nicht bröckelig. Bröckelig wird's erst, wenn du die Haustür und zugleich die Badezimmertür offenlässt und so jedermann deiner Frau beim Duschen zuschauen kann. ;-)

Was ich damit sagen möchte: Wenn du jemandem den Zugang zu deinen Passwort-Hashes erlaubst, bist du selbst schuld, wenn sie geknackt werden. Die Sollbruchstelle ist in diesem Fall ja wohl eher die offene Haustür in Kombination mit der offenen Badezimmertür ...

Übersetzt bedeutet das in diesem Fall, dass du deiner Frau nicht mehr erlaubst, sich zu duschen, nur weil du unfähig bist, die Türen richtig abzuschließen.

Genau so könnte der Gedankengang bei den Programmierern der Ashley-Madison-Platform gewesen sein.

Erst heisst es "Das passiert doch nicht" oder "Ist doch nur für Oma" und nach dem GAU hört man dann "Ich dachte ..." oder auch sehr beliebt "Aber das haben wir immer so gemacht" :roll:

Standard-Reaktion meinerseits ist dann nur noch "Ja, Ja" - damit ist alles gesagt, jedes weitere Wort ist überflüssig

[PeterPanino]

Nun, gut. Aber abgesehen von Passwort-Hashes: Um die Integrität einer Datei zu testen, kann ich wohl noch MD5File verwenden, oder? Oder ist das auch zu unsicher?

[BUG]

Zitat:

Zitat von PeterPanino (Beitrag 1316508)

Nun, gut. Aber abgesehen von Passwort-Hashes: Um die Integrität einer Datei zu testen, kann ich wohl noch MD5File verwenden, oder? Oder ist das auch zu unsicher?

Ja, es ist unsicher. Natürlich lässt sich abwägen, ob man das Risiko eingeht; aber abgesehen von Kompatibilität mit Legacy-Anwendungen: warum sollte man nicht eine der gut verfügbaren, sicheren Alternativen benutzen?

[Zacherl]

Zitat:

Zitat von BUG (Beitrag 1316510)

Zitat:

Zitat von PeterPanino (Beitrag 1316508)

Nun, gut. Aber abgesehen von Passwort-Hashes: Um die Integrität einer Datei zu testen, kann ich wohl noch MD5File verwenden, oder? Oder ist das auch zu unsicher?

Ja, es ist unsicher. Natürlich lässt sich abwägen, ob man das Risiko eingeht; aber abgesehen von Kompatibilität mit Legacy-Anwendungen: warum sollte man nicht eine der gut verfügbaren, sicheren Alternativen benutzen?

MD5 ist halt sehr schnell und wird teilweise sogar hardwareseitig von diversen Chips unterstüzt. Es kommt halt immer drauf an. Will man irgendwelche Dateien in einem Sicherheitskontext hashen, um Dateiintegrität zu gewährleisten, dann sollte man hier auch nicht auf MD5 setzen, da wie schon beschrieben einige Tools zur Berechnung von Kollisionen existieren.

Gehts nur schnell mal um ein inkrementelles Backup Programm oder sowas, sehe ich absolut kein Problem bei der Verwendung von MD5 oder sogar CRC32.

Wobei selbst bei der Integrität kann man nochmal unterscheiden. Ist es fatal (für eine Serverseite, 3. Clienten, etc), wenn die Datei fehlerhaft/manipuliert ist, oder geht es nur um einen lokalen Check als Komfortfunktion für den User.

Achso:
PHP >= 5.5.0 unterstüzt PBKDF. Dieses Verfahren wurde extra zwecks Passwort Authentifizierung entwickelt (http://php.net/manual/de/ref.password.php)

[BUG]

Zitat:

Zitat von Zacherl (Beitrag 1316512)

wird teilweise sogar hardwareseitig von diversen Chips unterstüzt

Was auch für SHA-1 und SHA-256 gelten kann ... wobei man SHA-1 im Zweifelsfall auch nicht mehr benutzen sollte.

Zitat:

Zitat von Zacherl (Beitrag 1316512)

Achso: PHP >= 5.5.0 unterstüzt PBKDF. Dieses Verfahren wurde extra zwecks Passwort Authentifizierung entwickelt (http://php.net/manual/de/ref.password.php)

PHP ist ja auch am meisten davon betroffen: viele Anfänger (neben den Profis :wink:) und die Software ist am Ende im Internet.

[PeterPanino]

Vielen Dank für euren wertvollen Input!

Welche optimale Alternative würdet ihr für FileMD5 in Delphi vorschlagen?