<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 20, 2014 at 6:22 AM, Jerry Leichter <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br></div>
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. </blockquote><div><br></div><div>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.<br>
</div><div><br></div><div>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.</div>
<div><br></div><div>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.)</div>
<div><br></div><div>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.</div>
</div></div></div>