Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85598
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Message-ID: <0CB1052E-0245-406D-8CF0-83E0D75CD049@gmail.com>
Date: Tue, 31 Mar 2015 21:13:50 +0200
References: <CAAyV7nGRU6J=-VRJ48=U4wNgE9vpk2k3fvz9MLnC2-VoCsyGRw@mail.gmail.com>
In-Reply-To: <CAAyV7nGRU6J=-VRJ48=U4wNgE9vpk2k3fvz9MLnC2-VoCsyGRw@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Subject: Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?
From: nicoswd@gmail.com (Nicolas Oelgart)

> On 31 Mar 2015, at 20:49, Anthony Ferrara <ircmaxell@gmail.com> wrote:
>=20
> All,
>=20
> Ever since we introduced password_hash() in 5.5, I've been watching
> its usage as much as possible. I've setup google alerts and such, as
> well as auditing implementations I've found on github to try to
> understand how it's used.
>=20
> One thing has become abundantly clear to me: the salt option is
> dangerous. I've yet to see a single usage of the salt option that has
> been even decent. Every usage ranges from bad (passing mt_rand()
> output) to dangerous (static strings) to insane (passing the password
> as its own salt).
>=20
> I've come to the conclusion that I don't think we should allow users
> to specify the salt. The crypt() API still exists if users have a need
> to generate their own salt. Having it in the simplified API is simply
> adding a risk factor without any significant justification.
>=20
> So I'd like to hear your thoughts about raising E_DEPRECATED when the
> salt option is specified in 7.0, with ultimately removing the option
> in a later version.
>=20
> Additionally, I know this is after the RFC freeze deadline, so if you
> want to postpone the deprecation to 7.1, that's fine. I just think
> it's worth discussion (and if there's consensus to put it in 7.0, then
> great).
>=20
> Thanks,
>=20
> Anthony
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

+1

I'd even go as far as adding a big red warning about custom salts to the man=
ual page.=20=