Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60992
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU4iPak5L3Ei=TKS9cnBY_vpEbRCbzSeqt8VUGye-m60Nw@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>
Date: Wed, 27 Jun 2012 08:24:39 -0400
Message-ID: <CAAyV7nEq98jokXwu2eu4oiOpkEvQTEMaFb2fKk3DE=tiUi9-zQ@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Gustavo Lopes <glopes@nebm.ist.utl.pt>, Simon Schick <simonsimcity@gmail.com>, 
	internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
From: ircmaxell@gmail.com (Anthony Ferrara)

Pierre,

>> As I understand, hashes computed with the old default method could still=
 be
>> checked without any modification as the hash itself stores information a=
bout
>> the method.
>
> That's only about one relatively simple use case where only PHP would
> be involved or crypt-like implemenation. For any other and rather
> common cases, it won't. I do not think a default should be implemented
> and actually let the user knows what he uses and what he is doing.
> That's one argument after all and clears all possible caveats.

Well, the argument could be made that if you need portability in that
respect, that you should be using `crypt()` or the other library
directly. This API is designed for the common use-case that impacts
99.9% of developers, where their applications will be the only ones
accessing the passwords. And even if in the future they need to access
it from a different system entirely (python for example), we're only
implementing standard algorithms. So there should be a python binding
available to verify (and hash) those passwords.

This won't take the place of crypt() or other libraries. It's only
there to solve the lowest common denominator in a dirt simple way. I
think removing the default (and forcing an algorithm specification)
kind-of defeats that point a little bit. It's not the end of the
world, and I could possibly be convinced, but I'm skeptical.

As for the issue you raised, I think that could be handled in the
documentation. Perhaps something to the effect of:

> PASSWORD_DEFAULT - This is the default algorithm that password_hash will =
use if none is specified. Note that this is designed to change over time as=
 newer and stronger algorithms are implemented. If you need to stay with a =
single algorithm (for portability or other reasons), it's recommended to al=
ways specify the algorithm in the function call.

Actually, now that I'm talking that out, perhaps the way to do it
would be to specify the default algorithm in a php.ini parameter
instead of the constant? That way the API can stay the same, but gives
people more control over the default creation... Then again, maybe
not.

Thoughts?

Anthony