[Cryptography] CSPRNG for password salt

John B vertex.vr4 at gmail.com
Wed Aug 20 00:23:32 EDT 2014


Hi Jerry,

Thank you for a well considered response.
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.

In answer to your question - "Where did you see this?" here are the top 2
hits:

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Use_a_cryptographically_strong_credential-specific_salt
(As pertaining to salt) *"Use cryptographically-strong random [*3] data;"*

https://crackstation.net/hashing-security.htm#properhashing
*Salt should be generated using a Cryptographically Secure Pseudo-Random
Number Generator (CSPRNG). CSPRNGs are very different than ordinary
pseudo-random number generators, like the "C" language's rand() function.*

Regards,
John


On 20 August 2014 12:54, Jerry Leichter <leichter at lrw.com> wrote:

> On Aug 19, 2014, at 9:43 PM, John B <vertex.vr4 at gmail.com> wrote:
> > 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.
> Where did you see this?
>
> > What are the reasons for this? Specifically:
> > a) What is the attack on a password hash generated with non-CSPRNG salt
> such as a rand() call?
> > b) How realistic/plausible is such an attack?
> 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.
>
> 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.
>
> 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.
>
> 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.)
>                                                         -- Jerry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140820/1e8518f8/attachment.html>


More information about the cryptography mailing list