Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60883
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAOMtwbSh8i=rMuY0W8YcPdit_ry9UGKg0=8g6sdaCx-_qeQx1A@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>
Date: Mon, 18 Jun 2012 14:04:33 -0400
Message-ID: <CAAyV7nEBGC3jrRakjjsQj5XcYA38YEKk6t84JouQHf_6CLxJ3A@mail.gmail.com>
To: Enrico Zimuel <e.zimuel@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Adding a simple API for secure password hashing?
From: ircmaxell@gmail.com (Anthony Ferrara)

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/Password/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.  But 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=%22password_validate%28%22&search.x=0&search.y=0&la=PHP&li=*&scope=
)

Anthony