Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60897
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nEBGC3jrRakjjsQj5XcYA38YEKk6t84JouQHf_6CLxJ3A@mail.gmail.com>
References: <CAF+90c-6VWJ_kBW=Z8Br-NOxKyuTkwStRg-OMBa6844w3=CjDA@mail.gmail.com>
	<8714BC2A-45E2-4303-9769-8399AF316159@gmail.com>
	<CAEZPtU6tXBgnTuGOfnjjFYyFJQ5iKpWX2Tq1U+wEaoyvBchW7A@mail.gmail.com>
	<3B162E01-67F6-4684-ACE7-40CAF73E9DC3@gmail.com>
	<CAEZPtU7scvZegC8udp2eM65hYGHX4F-B_109GPMrXETOBjpRWg@mail.gmail.com>
	<CAAyV7nEfoBKeCJe8pXZQJWi+MD7JrrOTjSV8RJpvq=mGYL5iGg@mail.gmail.com>
	<CAOMtwbSh8i=rMuY0W8YcPdit_ry9UGKg0=8g6sdaCx-_qeQx1A@mail.gmail.com>
	<CAAyV7nEBGC3jrRakjjsQj5XcYA38YEKk6t84JouQHf_6CLxJ3A@mail.gmail.com>
Date: Wed, 20 Jun 2012 08:07:32 +0200
Message-ID: <CAOMtwbTFdbFy3tU3CywxFkF7MJrAnPp-LO_iTd=PAg7VHMJ02w@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: 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: e.zimuel@gmail.com (Enrico Zimuel)

Hi Anthony,

I'm not sure about the idea to have a specific SPL for password hashing.
I like the idea to have a standard interface for that but maybe is
enough just a set of functions.
I see a valid argument to have a standard interface especially for the
password_register_algo().

Enrico

2012/6/18 Anthony Ferrara <ircmaxell@gmail.com>:
> Enrico
>
>> I like your idea to offer a wrapper of crypt() with a better API
>> (actually I used this approach in the ZF2 project:
>> https://github.com/zendframework/zf2/blob/master/library/Zend/Crypt/Pass=
word/Bcrypt.php).
>
> Yeah, crypt() is really nice, and offers a lot of good things out of
> the box. It's just the salt generation and error handling that are a
> pita...
>
>> I think we should also support the user's salt as option and generate
>> a random salt if not provided.
>
> Yeah, that could be good. The only part we'd need to be careful of is
> error checking the salt (correct length, correct format, etc). But in
> general I like the idea...
>
>> For the random generation I suggest to use as first option the
>> openssl_random_pseudo_bytes() that is considered more secure compared
>> with mcrypt_create_iv($size, MCRYPT_DEV_URANDOM).
>
> Well, the point wasn't to make a CS secure salt. We've already had
> discussions on that (it's not needed, and can harm the system to try
> to use CS salts). All salts need to be is unique (statistically unique
> is usually good enough). If people really want to use a CS salt, they
> should pass one in as the user-generated salt. =A0But I'd really like to
> voice my opposition to having this function default to CS secure salt
> generation...
>
>> I just wrote that changes here: https://gist.github.com/2949592
>
> Looks good to me otherwise.
>
> I expanded my original gist a bit to add in the ability to register
> your own algorithm:
>
> https://gist.github.com/2949382
>
> That way, existing projects that use things like PHPASS can register
> their own handler, and move towards this (let the fallback happen in
> password_validate instead of in user code).
>
> If we're going to go with this option (the series of functions), what
> do you think of putting them under spl:
>
> \SPL\password_create()
> \SPL\password_validate()
> \SPL\password_register_algo()
> \SPL\password_create_salt()
>
> Instead of doing it class based as was originally suggested?
>
> The reason for namespacing is that password_validate is used in the
> wild (not by many:
> http://www.koders.com/default.aspx?s=3D%22password_validate%28%22&search.=
x=3D0&search.y=3D0&la=3DPHP&li=3D*&scope=3D
> )
>
> Anthony