Gerade im Bereich Sicherheit geht es darum, alle einfach umsetzbaren Mittel, die zu einem Plus an Sicherheit führen, anzuwenden

Mein Gott! Das Plus an Sicherheit gibt es nicht. In PHP vor 5.3 gab es keine Möglichkeit, kryptographisch sicheren Zufall zu erzeugen. Insbesondere nicht random_int(). In PHP 5.3 und später wurden meine Ersatzfunktionen gar nicht benutzt und konnten ergo die Sicherheit gar nicht mindern. Die Sicherheit der mit meinem Skript gehashten Passwörter war also stets auf dem jeweiligen "Stand der Technik" und wird es so lange bleiben wie PHP diesen mit den password_*-Funktionen unterstützt. Die Behauptung war aber, mein Skript sei unsicher - und diese Behauptung ist falsch.

Du sprichst hier von perfektem Zufall und baust darauf deine Argumentation darauf auf.

Wie, bitte, soll ich denn sonst vorrechnen, wie sich der unperfekte Zufall auswirkt, wenn ich nicht den perfekten Zufall gegenüberstelle? Das habe ich getan und also meine Argumentation gerade nicht auf dem "perfektem Zufall" aufgebaut sondern auf dem "Unterschied zwischen perfektem und unperfektem Zufall".

Die Behauptung war, nur durch perfekten Zufall bei der Zusammensetzung des Salts wären die Passwörter sicher gehasht. Das ist aber nicht der Fall, weil es eben nur darauf ankommt, dass zu jedem Passwort ein anderer Salt verwendet wird um die Anzahl der notwendigen Rainbow-Tables groß zu halten. Die nachgeschobene Behauptung, dass einem Angreifer das Spekulieren vereinfacht würde, ist bei dieser technischen Anwendung einfach neben der Sache weil betreffs des Hashes nicht spekuliert wird

Auch die Belege für Sicherheitsverletzungen durch schlechte Zufallsfunktionen waren neben der Sache. In allen diesen Fällen wurde fortlaufend etwas erzeugt, was vom Angreifer erraten werden musste und konnte - bei dem Passwort-Zeug muss aber der Salt vom Angreifer nicht erraten werden, just weil er den stets zusammen mit dem Hash bekommt.