Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75619
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.46 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAGa2bXYP4L-EVjqiTvrOjbiRvzQJ7zyTQyu78O1AEEkk7nwEhQ@mail.gmail.com>
References: <CAGa2bXYP4L-EVjqiTvrOjbiRvzQJ7zyTQyu78O1AEEkk7nwEhQ@mail.gmail.com>
Date: Wed, 16 Jul 2014 16:53:07 -0700
Message-ID: <CAESVnVqBxo0VCYM_4V4_KzrD1+-F-0ipumrr_a=mAwaYje10Og@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] crypt() BC issue
From: pollita@php.net (Sara Golemon)

On Tue, Jul 15, 2014 at 5:46 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> crypt() has BC issue with older systems.
>
> https://bugs.php.net/bug.php?id=62372&edit=1
>
> The reason rounds became 1000 from 10 is hardcoded lower limit for newer
> PHPs.
> Generally speaking, developer should never use less than 1000 rounds and
> better to have
> at least few thousands rounds or more, tens of thousands or more is
> recommended.
>
> I would like to make this bug report 'wont fix', since migration is
> possible.
>
>  - Developer may use larger rounds and store updated hash when
>    user is authenticated with old PHP.
>  - Developer may ask users to reset password if password hash has
>    to fewer rounds than 1000 (i.e. outdated hash) with new PHP.
>
At the risk of perhaps missing the point, wouldn't it be more useful
to encourage users in some way (perhaps through documentation only) to
use password_hash()/password_verify() instead?  It was designed with
migration paths in mind.

Apps which are currently using crypt() for their own password systems
(the ones you would have migrate to crypt() + 1000 rounds) should be
pointed at the right solution, not placated with an "okay for now, but
may need to be migrated again later" route.

As far as I'm aware, the only reason for not marking crypt()
E_DEPRECATED right now is for compatibility with external systems, and
as far as those go, changing a default won't effect anything.

-Sara