Mathematik zum Montag

[1unitedpower]

Welcher Teil ist dir denn unklar geblieben?

1. Ist es nicht so, dass bei einem Lauf unter PHP ab 5.3 statt der auf rand() zurückgreifenden die originalen PHP-Funktionen password_hash() und password_verify() benutzt werden, dass also deine Einwände nur dann gelten könnten, wenn das System ohnehin unsicher ist?

Ja, das habe ich auch in meinem ersten Beitrag schon so ausgesagt.

2. Ist es nicht auch so, dass ein Angreifer, der den Angriff gegen mehrere hashes führen will um die Passwörter zu ermitteln, den salt ohnehin kennt, weil der, und der Indianerversteher hat das mehrfach beschrieben, der salt direkt dort steht, wo auch der hash steht? Ist es also nicht so, dass der demnach bekannte salt gar nicht erraten werden muss?

Wie schon erklärt, kann der Angreifer schon bevor er in den Besitz eines Salt+Hash-Paares gelangt, eine Lookup-Tabelle konstruieren. Wenn er dann schließlich in den Besitz eines solchen Paares kommen sollte, profitiert er von dem von mir beschriebenen Laufzeit-/Speicherplatz-Tradeoff.

3. Ist es nicht so, dass du dafür den seed() setzen musst bevor die salts erzeugt werden? Also Zugriff auf den Server brauchst?

Nein, irgendein Seed wird von PHP zufällig ausgewählt. In dem von mir beschriebenen Szenario macht der Angreifer sich zu nutzen, dass es verhältnismäßig wenig potenzielle Seeds gibt.

4. Es wurde (siehe Quelltext) in einer beachtlichen Anzahl von Runden zum hashen BLOWFISH und SHA512 verwendet. Ganz spitzfindig frage ich nochmal, wo und und zu welchen Kosten wie Du die Rainbowtables (deren Nützlichkeit Du behauptest - siehe Frage 2) 4.a) auch nur für einen Salt erzeugen und 4.b) speichern willst. Die entstehenden Datenmengen sind nämlich gewaltig.

4.a. Ich kann alle Seeds der Reihe nach aufzählen, dann starte ich für jeden Seed den Salting-Algorithmus aus dem Skript. So komme ich an alle maximal 2^32-1 möglichen Salts.

4.b. Ja, die Datenmengen sind gewaltig. Aber Speicherplatz ist günstig und wird ständig günstiger. Wenn dazu kriminelle Energie im Spiel ist, wird der Angreifer möglicherweise nicht mal den Marktpreis für den Speicherplatz bezahlen, sondern ein illegales Bot-Netzwerk dafür benutzen.

Man tut gut daran, davon auszugehen, dass einem potenziellen Angreifer deutlich mehr Ressourcen zur Verfügung stehen als einem selsbt.

Aber ich finde es ist aus der Art der Frage erkennbar, dass du schon eine Antwort darauf hast, denn es sind überhaupt keine Fragen, sondern verklausulierte Feststellungen.

Nun, die könnten ja falsch sein. Sind diese "verklausulierte Feststellungen" aber richtig, dann ist belegt, dass die Gründe, aus denen heraus 1unitedpower das Skript als "unsicher" behauptet, unzutreffend sind.

Ich hätte besser kryptografisch schwach anstatt kryptografisch unsicher geschrieben, das wäre die präzisere Wortwahl gewesen. Sicher ist kein qualitatives Merkmal, sondern ein quantitatives, wenn auch schwierig zu beziffern. Je weniger Angriffsoberfläche ein Skript bietet, desto sicherer würde ich es einstufen. Salting mit Pseudozufall ist um Größenordnungen besser als überhaupt kein Salting. Salting mit kryptografisch sicherem Zufall ist um Größenordnungen besser als kryptografisch schwaches Salting. Die Investionskosten für kryptografisch schwaches bzw. starkes Salting unterscheiden sich aber nicht, wieso würde ich mich also mit weniger zufrieden geben?