Um das ernsthaft und ausgeglichen zu diskutieren, bräuchten wir jetzt erstmal die Gründe, die zu dieser Aussage geführt haben - die führst du aber nicht an, sondern nur die dagegen.
Weil ich die Gründe, die für eine Notwenigkeit kryptographischen Zufalls beim Erstellen der Salts sprächen, nicht kenne und auch nicht erkennen kann. Das einzige "Argument" welches gebetsmühlenartig wiederholt wird, ist dass andere das behaupten. Über diese anderen wird ebenfalls nur behauptet, dass diese rennommiert seien. Ich sehe keinerlei sachlich fassbaren Vortrag außer
Wenn [→ Weil] der Pseudozufallsgenerator nicht genügend Entropie liefert,
... der aber leicht zu entkräften ist:
Denn der Pseudozufallsgenerator nicht genug Entropie für Kryptographie liefert, dann wird der Pseudozufall wohl immer noch für den von mir postulierten Zweck ausreichen. Wie oft könnte man mit rand() wohl 200 oder 2000 Salts mit 16 Zeichen aus [0-9A-Za-z/.] konstruieren bis man das erste Mal den Fall hat, dass dabei pseudozufällig 2 gleiche Salts in der gleichen Gruppe entstehen? (Das ist das einzige, um was es geht!) Ein paar Millionen oder ein paar Billionen mal?
Für mehr als 2000 gehaschte Passwörter ist doch schon die Speichermethode (text/csv) ungeeignet!
Meine sachlicher, auf die "Regenbogentabellen" bezogener Einwand
Die Kernfrage ist, wozu ich einen salt mittels kryptographischem Zufall bauen soll, wenn doch klar ist, dass die einzige Anwendung, bei der ein kryptographischer salt Vorteile bringen könnte, voraussetzt, dass der hash bekannt ist.** Mithin müsste dem Angreifer also zwar der hash nicht jedoch der salt bekannt sein, was im Hinblick darauf, dass beide in einem String stehen, "ziemlich selten wäre" - oder?**
wird zu Gunsten irgendwelcher Veröffentlichungen (die auch keinen Grund nennen) von irgendwem (dessen Autorität dadarch bestimmt wird, dass er in einem "Wir tragen das gleiche T-Shirt-Verein" ist) einfach - und mit beachtlicher Sturheit - negiert.