[Cryptography] CSPRNG for password salt

[Patrick Mylund Nielsen]

On Wed, Aug 20, 2014 at 6:22 AM, Jerry Leichter <leichter at lrw.com> wrote:

>
> 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.


There are several software packages that exist solely to coordinate
incrementing values like ID columns in a distributed database. If your
system isn't distributed, you may not have this problem at all, and it may
indeed be easy.

This counter vs. CSPRNG debate is analogous to the choice between using an
incrementing ID vs. using an UUIDv4 in any other kind of database. With
UUIDv4 you risk a few collisions, but it is significantly easier to manage
because no coordination is necessary. There is no need for nodes to speak
to each other to make sure an ID (or salt) isn't taken--as long as you can
live with the small risk of occasional collisions--nor is there a need to
store and manage access to the associated bookkeeping state.

Is CSPRNG output necessary for a salt? Clearly not. But it does remove a
lot of potential pitfalls, and regular developers should not be expected to
understand all the implications for either approach (although they probably
shouldn't be generating salts by themselves either.)

Besides, this is already settled in practice: Pick most any general-purpose
password authentication library, and chances are it generates salts using
urandom (or similar) under the covers. It's just easier that way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140820/21d0afe4/attachment.html>