Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61118
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nFkAfzR1dAA2ooYOkU8FbEmYu5V_1E+oeBb87jNaVz3mA@mail.gmail.com>
References: <CAAyV7nH6FCZUqrirJ0uOApuwR64Cky3cVnRfbrcjkZrpOKiN6w@mail.gmail.com>
	<e20a4ae344a2a5842ff244368138b4e4.squirrel@www.l-i-e.com>
	<CAAyV7nEN=nph0n_vs=wttd3v=SaN28Vur6nwLO5iYJFsVGi8aQ@mail.gmail.com>
	<ca8026ff6ee7a84a3fc1fc53252e37b7.squirrel@www.l-i-e.com>
	<CAAyV7nFkAfzR1dAA2ooYOkU8FbEmYu5V_1E+oeBb87jNaVz3mA@mail.gmail.com>
Date: Mon, 9 Jul 2012 11:19:44 -0400
Message-ID: <CAAyV7nHT9H_mbsO=PmW25vRMBs+4NVa170oifZ2SKZDwCnNR3g@mail.gmail.com>
To: Richard Lynch <ceo@l-i-e.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf3074d5b8ca950604c46724c5
Subject: Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
From: ircmaxell@gmail.com (Anthony Ferrara)

--20cf3074d5b8ca950604c46724c5
Content-Type: text/plain; charset=ISO-8859-1

I've added a pair of new functions to the RFC and implementation:

password_needs_rehash($hash, $algo, array $options = array())
and
password_get_info($hash)

both are reasonably similar and there's a fair bit of overlap. Considering
that password_needs_rehash can be implemented easily in user-land, I'm not
convinced it's needed. Then again, it's easy to implement and shouldn't
pose a maintenance headache, so I'm not sure if it shouldn't be there
either...

What do you think?

Anthony

On Tue, Jul 3, 2012 at 5:24 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:

> Richard,
>
> > There is also the case of an app that simple shouldn't run with the
> > single default, but could pick and choose suitable algorithm from a
> > list of defaults, while still honoring whatever is in the .ini file
> > instead of going rogue with some other algorithm.
>
> I disagree there. I think that's up to the application to decide. A
> list of defaults does nothing but needlessly complicate the
> implementation. How is the hash function supposed to determine which
> of the list of defaults to use? Let the application layer choose, and
> pass it in. The current PASSWORD_DEFAULT lives for the sole reason
> that it auto-updates to indicate the most secure algorithm available.
>
> Anthony
>

--20cf3074d5b8ca950604c46724c5--