Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61013
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: <CAEZPtU5OJg0Hk+1okCUuOWdScKjbPEoYQm3oryWUYWiP6mWKDQ@mail.gmail.com>
References: <CAAyV7nH6FCZUqrirJ0uOApuwR64Cky3cVnRfbrcjkZrpOKiN6w@mail.gmail.com>
	<CAJWj5+EA3vnNRMBxtVjcPhz1Ga5yqERkTnHoWsyx8Kxm05OEog@mail.gmail.com>
	<CAAyV7nETi6QxfAvPNFUzp02bX7Cm+ur5KnQH_CCahXH7qq7R_A@mail.gmail.com>
	<CAEZPtU7KGweFhOemFTc5O15DW4PK3qWErET+kx09Fa57JF2MhQ@mail.gmail.com>
	<op.wgj8g0h7idpuyk@damnation>
	<CAEZPtU4iPak5L3Ei=TKS9cnBY_vpEbRCbzSeqt8VUGye-m60Nw@mail.gmail.com>
	<CAAyV7nEq98jokXwu2eu4oiOpkEvQTEMaFb2fKk3DE=tiUi9-zQ@mail.gmail.com>
	<op.wgkaf1ocidpuyk@damnation>
	<CAEZPtU4bH9Mpj40OYP=k4oTQGhfdp3btf11GwvLUo59XS8O2uA@mail.gmail.com>
	<op.wgkbp1nxidpuyk@damnation>
	<CAEZPtU5OJg0Hk+1okCUuOWdScKjbPEoYQm3oryWUYWiP6mWKDQ@mail.gmail.com>
Date: Wed, 27 Jun 2012 22:06:52 -0400
Message-ID: <CAAyV7nG__nm9rEjdFvzeOcTAVBK1oss2FV5ixEYd0UbjoBZqXA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Gustavo Lopes <glopes@nebm.ist.utl.pt>, internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
From: ircmaxell@gmail.com (Anthony Ferrara)

Pierre,

> No, it is exactly one example out of many where changing values are a
> real pain to deal with over the years. We should not have one.

While I completely see your point (and don't disagree with it in
isolation), I also see the counter point of making it easy for people
to use. Knowing anything about algorithms to force the common
developer to make a choice between bcrypt and scrypt is unreasonable
IMHO. It's an implementation detail that they should know, but most
won't. Knowing the intricacies of the different algorithms is
something even most senior devs (who are not active in security at
least) don't understand. I'd rather present them best-case defaults,
and let them make the decision to diverge from them.

With that said, what about a compromise. What if we made the API:

password_hash($password, $algo, array $options = array())

And instead of just making the users choose which algorithm to use, we
provide a "moving" constant called

PASSWORD_MOST_SECURE

Which will be updated every major release (assuming there's an update
to apply) or in extreme circumstances (a serious flaw is found in the
current most secure algorithm, justifying a concern).

That way, people don't have to worry about moving targets, because the
core moves it for them as needed. But the choice has to be made. They
aren't just relying upon the default. And the documentation
surrounding it must indicate that if cross-platform interoperability
is a concern, pick a standard algorithm such as bcrypt and use just
that.

So then, a basic call would be $hash = password_hash($password,
PASSWORD_MOST_SECURE);

It solves both problems, while still being reasonably easy...

Thoughts?

Anthony