Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85597
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.174 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 19:58:10 +0100
Message-ID: <CAAn=CzWt6mQUNK39dYikcDhgwzL=uevi_P2hU1LbjLMxcA-k6g@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3aa740c3f8805129a2e4c
Subject: Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?
From: bowersbros@gmail.com (Alex Bowers)

--001a11c3aa740c3f8805129a2e4c
Content-Type: text/plain; charset=UTF-8

I think deprecating it is a good idea, and looking at the documentation it
does mention that not providing it is the intended option; so it isn't a
complete surprise for it to become deprecated.

On 31 March 2015 at 19:49, 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).
>
> Thanks,
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11c3aa740c3f8805129a2e4c--