<div dir="ltr"><div><div>Hi Jerry,<br><br>Thank you for a well considered response.<br>FWIW I agree with your bogus expansion theory. I also can't see any realistic attack but it's often better to be cautious and ask.<br>
<br></div>In answer to your question - "Where did you see this?" here are the top 2 hits:<br><br><a href="https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Use_a_cryptographically_strong_credential-specific_salt">https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Use_a_cryptographically_strong_credential-specific_salt</a><br>
</div>(As pertaining to salt) <i>"Use cryptographically-strong random [*3] data;"</i><br><br><div><a href="https://crackstation.net/hashing-security.htm#properhashing">https://crackstation.net/hashing-security.htm#properhashing</a><br>
<i>Salt should be generated using a <b>Cryptographically Secure Pseudo-Random
Number Generator</b> (CSPRNG). CSPRNGs are very different than ordinary
pseudo-random number generators, like the "C" language's 
<span class="">rand()</span> function.</i><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"></div><div class="gmail_extra">Regards,<br>John<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">
On 20 August 2014 12:54, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Aug 19, 2014, at 9:43 PM, John B <<a href="mailto:vertex.vr4@gmail.com">vertex.vr4@gmail.com</a>> wrote:<br>
> Some research on the interwebs turned up the recommendation that a password hash's salt should only be generated with a cryptographically secure PRNG. Some sources specifically mention *not* using rand() and friends.<br>

Where did you see this?<br>
<br>
> What are the reasons for this? Specifically:<br>
> a) What is the attack on a password hash generated with non-CSPRNG salt such as a rand() call?<br>
> b) How realistic/plausible is such an attack?<br>
The only purpose a salt serves is to make it impossible to reuse brute-force attacks made against a user whose password was hashed with one salt against a user whose password was hashed with a different one.  You could as well assign sequential salts to accounts as they are created.<br>

<br>
I can think of exactly one situation where the predictability of salts - which is the same whether you use sequential values or an insecure PRNG.  Suppose you knew that a large number of users would change their passwords at the same time.  (E.g., consider a university when students return from summer break).  If you knew the order in which the changes were applied, and how the salt was assigned, you would have the chance to predict the salt and pre-compute a rainbow table to allow you to rapidly attack a given password.<br>

<br>
Sounds like you'd need to have an unrealistic amount of information about exactly how the password changes were done, by an unrealistically deterministic password change process.  And even then, rainbow tables are a clever but essentially dead technique today, since one can use hardware to simply brute-force passwords at immense rates.  Knowing the salt ahead of time doesn't help for such attacks - they need the hashed password.<br>

<br>
Maybe someone has come up with a plausible attack based on the ability to predict salts - the only thing you're giving the attacker by not using a CSPRNG.  But this sounds to me more like a bogus expansion of something that started out, way back when, as sound advice.  (In fact, what it *may* have come from is advice not to *generate passwords for users* from a non-CS PRNG.  *That* makes sense, for pretty obvious reasons - but I'll bet it's been done by many an organization.)<br>

<span class=""><font color="#888888">                                                        -- Jerry<br>
<br>
</font></span></blockquote></div><br></div></div>