Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85600
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGRU6J=-VRJ48=U4wNgE9vpk2k3fvz9MLnC2-VoCsyGRw@mail.gmail.com>
References: <CAAyV7nGRU6J=-VRJ48=U4wNgE9vpk2k3fvz9MLnC2-VoCsyGRw@mail.gmail.com>
Date: Tue, 31 Mar 2015 21:41:47 +0200
Message-ID: <CAF+90c9J1sVehbueGq-PyS8u5pdDmKkK5z6=mut+0GfJHP8u4g@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1135e46203dd7505129aca10
Subject: Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?
From: nikita.ppv@gmail.com (Nikita Popov)

--001a1135e46203dd7505129aca10
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 31, 2015 at 8:49 PM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> All,
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> 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).
>

Agree with deprecating the custom salt option and also okay with doing it
in 7.0.

Nikita

--001a1135e46203dd7505129aca10--