[Cryptography] CSPRNG for password salt

[Taylor Hornby]

On 08/20/2014 04:22 AM, Jerry Leichter wrote:
> 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.

If you use a CSPRNG, you don't need to store state. It's conceptually
simpler than having counters and storing those counters, dealing with
race conditions on those counters, protecting that state from malicious
modification, etc. Just read from /dev/urandom and use that as your salt.

Using a counter is fine if you're in control of everything, but if
you're writing a password storage library with minimal dependencies, and
no database interaction, a CSPRNG is the way to go.

There's also the argument that computationally-expensive memory-hard
functions could depend on the unpredictability of their salt parameter
to guarantee hardness properties. I'm not sure if that's usually the
case, I assume it is, but check the PHC research to be sure.

A counter can give you local uniqueness, but a salt needs to be
globally-unique. You could combine the hostname with the salt, but even
hostnames are duplicated. The only way, as far as I know, to ensure a
value is globally-unique is with a well-seeded CSPRNG.

-- 
Taylor Hornby