Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60828
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGASuKuiTn5-5uP-mxidcP_mCM1cS6MqsT1EQkOTUXkZA@mail.gmail.com>
References: <CAF+90c-6VWJ_kBW=Z8Br-NOxKyuTkwStRg-OMBa6844w3=CjDA@mail.gmail.com>
 <CA+yzxZhx9YVarc7dYJYf5LPnTxR6eR3RYa43QsgFOe+DCw7t-Q@mail.gmail.com>
 <CAAyV7nGJRGO9tu_UKsO+nVAp5Ks_HTsGCU+4TF2i7MeJmvkSrw@mail.gmail.com>
 <CAEU6NAdCUBxtrJkXuOAkKWn2j1eASkUeaXQmXZW7H91yKP7+Cg@mail.gmail.com> <CAAyV7nGASuKuiTn5-5uP-mxidcP_mCM1cS6MqsT1EQkOTUXkZA@mail.gmail.com>
Date: Thu, 14 Jun 2012 16:26:07 +0200
Message-ID: <CAEU6NAddGuoU7B_BZs12gbADjEZc-DLcDBPpP-dBUm+fTc0CZg@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Adding a simple API for secure password hashing?
From: peter.e.lind@gmail.com (Peter Lind)

On 14 June 2012 15:35, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> Peter,
>
>> Whether or not a CSPRNG is needed depends on what you're doing, your
>> needed level of security. Perhaps add a parameter to control this, so
>> it would be possible to make use of this function even if you need the
>> maximum level of security? If it's not available, the function should
>> fail in some suitable fashion.
>
> For password hashing, it won't ever be needed for the salt. The salt
> is not a secret in the context of cryptography. But, on that note, if
> we were adding a stronger PRNG generator, it would be good to expose
> it natively. And that native exposure would likely take a parameter
> for CS-safe PRNG...

I would say it really depends upon the project. The salt can not only
protect against rainbow tables and password hash collisions, if it is
unknown to an attacker then it essentially acts to further strengthen
the hash by vastly expanding the keyspace. Supposing an attacker is
trying to get at the password for just one user account (say, admin)
and the hashed password is available - if the salt can be
predicted/guessed, then the keyspace is reduced to that of an unsalted
password and you can run a dictionary attack on the hash. If, on the
other hand, the salt is unpredictable and you don't have access to it,
there is no way to run a dictionary attack (offline, that is). The
security here depends upon storage as well, but the point remains - a
salt isn't by default something you can make public knowledge.

It might be a theoretical concern for most people and the people
really wanting the extra level of security would probably know well
enough how to get exactly what they need - but if provisions are made
so you could reuse the same function you might also be able to educate
developers better. I.e. make it easy to do the right thing and more
people will do it.

Regards
Peter

-- 
<hype>
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
</hype>