Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60989
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20120627092217.GA16399@openwall.com>
References: <CAF+90c-6VWJ_kBW=Z8Br-NOxKyuTkwStRg-OMBa6844w3=CjDA@mail.gmail.com>
	<CAKOpQSzHLWhQxe9D2hjAo+O4AevoAEL4vFAhkoyxiZS8fvc3GA@mail.gmail.com>
	<CAAUB37CP1pCKCAvvQ56EkeT_0VdjpXwd_=FnQct+9XZTou0_GA@mail.gmail.com>
	<CAAyV7nEKuta7rFx2ZAQQyD6JMA6z2G3UGF-ETmPbcs73vy74GQ@mail.gmail.com>
	<CAEZPtU7pH1mW-_sF1pPw=-8zYG-cFEd8XQk7N4KnWFNuKF3jAQ@mail.gmail.com>
	<20120627092217.GA16399@openwall.com>
Date: Wed, 27 Jun 2012 07:51:38 -0400
Message-ID: <CAAyV7nHBSCasLi1BzvRx09LjMF0GgnO_s0ydGiY=asXCVgp4Sw@mail.gmail.com>
To: Solar Designer <solar@openwall.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Herman Radtke <hermanradtke@gmail.com>, 
	Nikita Popov <nikita.ppv@googlemail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Adding a simple API for secure password hashing?
From: ircmaxell@gmail.com (Anthony Ferrara)

Alex,

> Thank you for the chance to comment, and sorry that I did not do so yet.
> I am busy with lots of other stuff. =A0I'd appreciate it if you don't
> hurry to implement this stuff too much, and I likely will comment on it
> (that is, on the actual proposed API and implementation). =A0Please keep
> me in the loop.

It's not a huge rush, but at the same time I'd like to get it in by
5.5. The RFC process takes at minimum 3 weeks from official proposal
(2 week discussion + 1 week voting). And I haven't officially proposed
it yet. So there's still some time.

> Note: _if_ you ask for a portable hash. =A0What else should it do if you
> ask it for just that?

That's a fair point. I guess since the adoption of 5.3, and the fact
that 5.2 is dead (yet alone php4), has me thinking that "portable"
means something different today than it did then...

>> > So for modern versions
>> > of PHP (5.3+), it produces an unnecessarily weak hash.
>
> For modern versions of PHP, if you don't require portability of hashes
> to older versions, don't ask it for a portable hash.

That's fair. Perhaps the documentation needs updating to indicate that
*portable* really just means compatibility with php <=3D 5.2...

> Of course, new PHP apps that will depend on your new API won't run on
> older versions of PHP by definition, so they could assume bcrypt is
> available. =A0A concern, though, is that by the time major web apps would
> be able to assume a recent enough version of PHP (with this new API)
> we'll prefer to use a password hashing method with more than one
> configurable parameter (not just one "cost" setting), so we may want to
> design the API with that in mind.

That's a very good point. And it's already designed into the API.
Right now, it only implements one algorithm in the core, but the
switches and options are all there to support multiple. I just didn't
see any solid reason to include the other (slightly less favored)
crypt() hashes available today (SHA512 for example). But it's designed
so that they can be added easily. I know there's talk floating around
the list with respect to adding scrypt support into core. If that
happens, it would definitely be added to the implementation.

> Additionally, I was/am going to experiment with implementing a decent
> KDF in PHP, but also considering its native reimplementation at the same
> time (for inclusion in PHP proper, etc.) =A0That way, we could have hashe=
s
> that are both portable (to older versions of PHP, to other scripting
> languages, etc.) and efficient. =A0My expectation is that when implemente=
d
> in a scripting language (using a widely-available crypto primitive like
> SHA-512 or AES), they could be somewhere inbetween bcrypt and scrypt in
> terms of cost of attack - and when reimplemented natively, they could be
> approaching scrypt (although Colin's choice of Salsa20/8 core for the
> crypto primitive was not arbitrary, and unfortunately we don't have that
> in PHP). =A0I feel that there's room for exactly one such would-be
> de-facto standard "scripting KDF", and I might be in a position to set
> this standard due to phpass (this new thing could be a next generation
> phpass). =A0But I haven't decided on this yet, I'd need to experiment
> first, and I don't like to be rushed. ;-)

No rush at all. I like the concept though. Would it be worth while to
add an implementation of salsa20/8 to the core?

> http://www.openwall.com/presentations/PHDays2012-Password-Security/mgp000=
51.html
>
> I think it's OK/preferable not to introduce this new hash type earlier
> than in a year from now or so, unless there's imminent threat of someone
> else doing it substantially worse. ;-) =A0Meanwhile, I don't mind having
> an API that would provide bcrypt, even though I think that phpass does
> this well enough (and I intend to release a minor update to this first
> generation phpass). =A0As long as we're not introducing a new hash type t=
o
> this world yet, we are OK to experiment with APIs, etc.

Well, part of the reason for this API, is that it appears that the
majority of developers either aren't willing to use a library, or
don't know it exists (even though it's very easy to find if you try).

Additionally, I would think there would need to be a vetting period
for a new KDF like this (for review, and trial implementations and
such) before it would be considered "stronger" than bcrypt. If that's
the case, then the core implementation would work fine. You implement
the new KDF in a library. It goes through vetting and testing. if all
is good, when it's mature it can be added back into core in this API.

Thanks,

Anthony