Statt md5(str) - Das, was heise vorschlug in einf. Code gegossen

[Jörg Reinholz]

Noch einmal: Ich weiß nicht, warum man hier sämtliche Ratschläge von Experten ignorieren sollte.

NIST macht MIST.

Warum man dezidierte Krypto-Bibliotheken wie OpenSSL und mcrypt ignorieren sollte.
Warum man dezidierte Quellen für Pseudozufallszahlen wie /dev/urandom ignorieren sollte.

weil bei einem

$salt=dd if=/dev/urandom/ bs=32 count=1;

der dedlfix geschrieben hätte, man solle doch bitte, um Windows-Hoster nicht zu verärgern, in PHP bleiben statt Systemaufrufe zu tätigen?

Warum man ignorieren sollte, was in der PHP-Doku steht.

Weil da auch rand(), dann srand() mal als toller Zufallsgenerator gepriesen wurde? Es gibt, wenn er so besch... ist, wie Du behauptest, für die Macher von PHP keinen Grund den nicht zu reparieren.

Warum man ignorieren sollte, wie PHP es intern implementiert.

siehe rand();

Warum man ignorieren sollte, wie fertige PHP-Bibliotheken es implementieren.

siehe rand();

Warum man sich selbst etwas basteln sollte.

siehe das hier
Und weil man dann weiß, was das Ding macht, es also in anderen Sprachen ebenso bauen und bisherige Daten verwenden kann.

Und es gibt noch einen Grund. Wenn ich zeigen will man ein Brot bäckt, dann sage ich auch nicht:

• Man nehme die tolle Backmischung von Dr. Oh. und Wasser
• Man forme den Teig und stelle ihn 60 Minuten in den tollen Brotbackofen von S.

(Nachricht am nächsten Tag:  Backmischung von Dr. Oh. enthält krebserregende Stoffe)
(Nachricht am übernächsten Tag:  Brotbackofen von S. vergiftet Brot mit Schwermetallen)

Jeder Artikel, den ich finde, rät dazu, in PHP nicht rand() oder mt_rand() für Initialisierungsvektoren
oder Hash-Salts zu verwenden.

Soso. Du hast was übersehen. Ich verwende rand() nicht einmal, sondern 32 mal nacheinander und baue dann an einem String herum. Dazwischen passiert viel "Entropie". Und zwar andere "Entropie" als beim vorherigen und nächsten 32-maligen verwenden von rand(). Für Hashes mag das genügen, bei Initialierungsvektoren sehe ich das durchaus kritischer.

Es bleibt dabei. Wenn Du 100 Mio Salts mit meiner Methode erzeugst, dann erzeugst Du mit einer enormen Wahrscheinlichkeit 100 Mio verschiedene salts. Insgesamt gibt es (bei meiner Methode) theoretisch 6.9*10^32 verschiedene Salts - aller 10^26 (geschätzt, nicht gerechnet) Versuche hast Du also in jeweils 10 Mio Salts zwei gleiche. Und nur auf diese Diversität kommt es an! Denn die Salts sind ja sowieso bekannt - die stehen in den Daten!

Nochmal: Wichtig ist nur, in den 10 Mio (die Zahl ist nur ein Beispiel) Salts möglichst viele verschiedene sind. Auch 99.999.999 (und noch einer, der schon mal da war) reicht wohl um einem, der sich an das Ermitteln der Klartextpasswörter macht, das Leben sauer zu machen, denn er müsste für jeden Salt gigantische Rainbow-Tables errechnen- weisst Du was das kostet?