Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60830
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEU6NAddGuoU7B_BZs12gbADjEZc-DLcDBPpP-dBUm+fTc0CZg@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>
	<CAEU6NAddGuoU7B_BZs12gbADjEZc-DLcDBPpP-dBUm+fTc0CZg@mail.gmail.com>
Date: Thu, 14 Jun 2012 10:58:20 -0400
Message-ID: <CAAyV7nEn=L4zv=oJnfZWYBAygsCN+-gDWnURcYTgVWPhze4HKQ@mail.gmail.com>
To: Peter Lind <peter.e.lind@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Adding a simple API for secure password hashing?
From: ircmaxell@gmail.com (Anthony Ferrara)

Peter,

> 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.

That's not true. There are two types of secure algorithms in
cryptography. Those that are kept secure by a secret, and those that
are secure by effort. Hashing is an effort based algorithm. It's
difficult to reverse, so you need to brute force, expending a lot of
effort in the process... Salts are designed to make that brute forcing
non-amortizable, only (meaning that the effort put in to brute force
one hash can't be applied to another). The way they are used in the
algorithms shows that. They are even stored directly with the hash in
a number of implementations (crypt being a key one). That should point
out how the security that a salt adds does not depend on it being
secret.

> 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.

Then it's not a salt. And unless you *really* know what you're doing,
it's not worth it, and at best you're not making it more secure (and
at worst, you're significantly reducing the security). Remember,
security through obscurity is not security. Check out this post, and
the comments from experts:
http://blog.ircmaxell.com/2012/04/properly-salting-passwords-case-against.html

> 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.

No, if people want the extra level of security, they should then
encrypt the hash with a secure key before storing it. Note that 2
algorithms would be in place, one proof of work, and one dependent
upon a secret. Trying to combine them because one parameter looks like
it could be a secret is not the way to go...

Anthony