Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61000
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL0xaBEVkdCqy6sorYn7fpgx3sGs4NNmj+BGLUfjUeD+UVTqDA@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>
	<CAAyV7nFY_BbKQ5BPZ8Huzrc7114n5XeibTRpJ-MSJhW9apPscg@mail.gmail.com>
	<CAL0xaBEVkdCqy6sorYn7fpgx3sGs4NNmj+BGLUfjUeD+UVTqDA@mail.gmail.com>
Date: Wed, 27 Jun 2012 10:16:07 -0400
Message-ID: <CAAyV7nFrr4YSokgeJmCam0rqz_hJmXtzsN9L6eGcTYY80phU=A@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Gustavo Lopes <glopes@nebm.ist.utl.pt>, 
	Simon Schick <simonsimcity@gmail.com>, 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)

Arvids,

On Wed, Jun 27, 2012 at 9:23 AM, Arvids Godjuks
<arvids.godjuks@gmail.com> wrote:
> Hello.
>
> I personally think that using PASSWORD_DEFAULT for algorythm by default is a
> bad idea. This should be defined by user in the code. Even worse if it is
> defined by .ini setting - deploy to a remote server and realize that there
> is a different .ini default that messes up everything. Lessons learned in
> the past are forgetten fast?

It wouldn't mess up anything. All it would do is change the algorithm
used by the library when creating new passwords. Existing ones will
still validate. The new ones will validate on the old server as long
as that algorithm is supported (could be an issue in a mixed
environment where there are servers using an older version without
support for the new method in crypt())...

> And the thing I don't get is how do I verify a salted password? I have read
> throught the RFC and what I know about the salts makes me wonder - how da
> hell I will verify my salted hash if I can't pass the salt to
> password_verify?

Ah, I think I see the disconnect. crypt() returns the full salt
information along with everything necessary to hash it (all settings).
So the generated hash includes the salt, the method, and the cost
parameter. For example:

var_dump(crypt("rasmuslerdorf", "$2a$07$usesomesillystringfor"));

string(60) "$2a$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi"

So just storing the hash is enough...

> If there is some trick behind, it should be explained in the RFC (and in the
> docs later, because otherwise it makes people WTF?! who are not into
> cryptography).

That's completely fair. I'll add a section to the RFC about that...

Thanks,

Anthony