[Cryptography] CSPRNG for password salt

[Jerry Leichter]

On Aug 20, 2014, at 6:14 AM, Erwan Legrand <erwan at lightbringer.org> wrote:
>> One more thing: using a CSPRNG to generate removes a possible cause of
>> failure. It is very easy to get counters or rand() wrong. For example,
>> think of a multi-process program such as Apache HTTP: all processes
>> inherit the same seed or initial counter value. Many users end up
>> having the salt.
>> 
>> So even if using a CSPRNG to generate salts does not make sense from a
>> theory point of view, it may make sense from en engineering best
>> practice point of view. (Although engineering best practice should
>> first recommend using an existing password hashing library if
>> possible.)
> 
> Here's another real life example, this time of a problem encountered
> with rand(). Calling some third party library function resulted in the
> seed being set to 0. I seem to remember that libxml2 does this.
This is a rather weak argument.  You're contrasting a CSPRNG - something that's quite difficult to build correctly, as we've seen from many discussions on this list - with something as simple as "remember the last one and add one to get the next".  We've had predictable "CSPRNG's" in the past.

If all you need for a salt is a value that won't be re-used, getting software that guarantees that won't happen is a very minor problem.  Arguing for CSPRNG's *on the basis that solving that problem is a likely source of weakness*, when there are *so* many much more complex things to get right, makes no sense to me.

                                                        -- Jerry