Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85595
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
Date: Tue, 31 Mar 2015 14:49:24 -0400
Message-ID: <CAAyV7nGRU6J=-VRJ48=U4wNgE9vpk2k3fvz9MLnC2-VoCsyGRw@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: password_hash() deprecate salt option - thoughts?
From: ircmaxell@gmail.com (Anthony Ferrara)

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).

Thanks,

Anthony