Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61895
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain openmv.com from 64.15.152.204 cause and error)
To: "'Anthony Ferrara'" <ircmaxell@gmail.com>
Cc: <internals@lists.php.net>
References: <CAAyV7nFRT24rksh6iDWxstfQwJ4+KdEC7Zs6EC8wBtJ8Zorf7w@mail.gmail.com>	<4FFF1831.8070902@sugarcrm.com>	<CAAyV7nHi0k6S-zbi5=xCE8EmXpaEds9RoZTB8RPOeO8K_ZLY=w@mail.gmail.com>	<005101cd6f18$9da38510$d8ea8f30$@com>	<CAAyV7nGOiVD0=z+6nJKAhr6qu96GuU4+nBTTQiizcP9DxNRUUg@mail.gmail.com>	<009401cd6f28$b71c69c0$25553d40$@com> <CAAyV7nH8w5j+AQYQqh0O5eA78tjrvEzAAvKkPNPNrRFhBvDxvQ@mail.gmail.com>
In-Reply-To: <CAAyV7nH8w5j+AQYQqh0O5eA78tjrvEzAAvKkPNPNrRFhBvDxvQ@mail.gmail.com>
Date: Tue, 31 Jul 2012 12:01:07 -0400
Message-ID: <00b701cd6f35$b2d621a0$188264e0$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Ac1vLHB71zIXuW6UQuOncC/0Z0ab1wABSHZg
Content-Language: en-ca
Subject: RE: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
From: jbondc@openmv.com ("Jonathan Bond-Caron")

On Tue Jul 31 10:54 AM, Anthony Ferrara wrote:
>=20
> On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron <HYPERLINK=20
>=20
> I strongly disagree with this, the 'pepper' IMHO is a best practice=20
> for web applications.
>=20
> Again, I have not seen this being said by any security or cryptography =

> expert.
>=20

Like I said IMHO, I'm not a security expect but I do think there needs =
to be
modern discussion around 'web password hashing'.

>
> Ok. So I register an account before I get the database. Now the only =
thing
that I need to crack is the pepper (since I know the salt, hash and =
original
password for my sentinel account).

Fair enough ;)

It can still be a problem if the pepper is large + the crypt() salt

>=20
> With all of that said, if you really want a secret in there, don't=20
> hijack the hashing algorithm to do it. There are two somewhat decent
> alternatives:
>=20
> HMAC the password with the secret prior to passing it to=20
> password_hash()/crypt(). =A0HMAC is secure and is designed for this=20
> exact purpose.
>=20

Not so great:
password_hash_rfc( hash_hmac('md5', 'password', '1024-bytes secret') ) =
//
hmac is short (~ 160bits)

I guess you mean:

hash_hmac('md5', password_hash_rfc('password'), '1024-bytes secret')

But then there's no way to know all those crypt() parameters, salt, =
cost,
etc...

Maybe a new api?
password_hash_hmac($password, $secret, $options =3D array());

>=20
> Encrypt the resulting hash with a secure encryption function
> (RIJNDAEL_128 + CBC) prior to inserting it in the database. That way,=20
> each component uses standard algorithms as they were designed to be =
used.
>=20

That's fine, I feel this should be somewhat easier in php core (without =
the
need for openssl & al.)

It also comes with a cost of decrypting the hashes / not so great

> But I want to stress something else. Properly managing secrets is VERY =

> difficult. It's not even really possible in PHP, due to the way=20
> copy-on-write works, and how variables are removed. To implement this=20
> sort of a system correctly is not something even highly competent=20
> developers can typically do. It really is that difficult to get right.
>

Sure managing keys properly can be hard, simple cases:=20
$secret =3D MY_KEY;
$secret =3D file_get_contents('/security/key.pem');

Again I'm making the assumption that the attacking *does not* have =
access to
the file system.