Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62575
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20120828155535.GR32129@phcomp.co.uk>
References: <CAAyV7nFRT24rksh6iDWxstfQwJ4+KdEC7Zs6EC8wBtJ8Zorf7w@mail.gmail.com>
	<CAAyV7nGbRzb5sMs3N7uz51d1c-2-2n51jfWYhZncstTv0GAtbA@mail.gmail.com>
	<20120828155535.GR32129@phcomp.co.uk>
Date: Tue, 28 Aug 2012 17:58:57 +0200
Message-ID: <CAH-PCH5u_4Ds=GOPUag8nDG72v4Ag7HuPhwoFnoBwnXhSUJC6Q@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=e89a8ff255c01f889004c85585f0
Subject: Re: [PHP-DEV] Re: [PROPOSED] password_hash RFC - Implementing
 simplified password hashing functions
From: tyra3l@gmail.com (Ferenc Kovacs)

--e89a8ff255c01f889004c85585f0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 28, 2012 at 5:55 PM, Alain Williams <addw@phcomp.co.uk> wrote:

> On Tue, Aug 28, 2012 at 11:28:07AM -0400, Anthony Ferrara wrote:
> > >
> > > Hello all,
> > >
> > > Since the discussion has died down around the concept, I have updated
> the
> > > RFC and moved it into Proposed (under discussion) status.
> > >
> > > I have updated the RFC to include a section on discussion points
> > > containing points that I know were raised but I felt were not closed
> (there
> > > was some debate or disagreement). I tried to include a simple
> description
> > > of both arguments, and the position the RFC currently takes and a bri=
ef
> > > reason why.
> > >
> > > https://wiki.php.net/rfc/password_hash
> > >
> > > Please have a look and provide any feedback!
> > >
> >
> > I've removed the password_make_salt() function from being exposed and
> > updated the RFC to indicate such. It can be added as a later change if
> > needed.
> >
> > I plan on opening the vote on this next week, so if there's anything el=
se
> > anyone wants to discuss, please speak up!
>
> Yes -- this is something that has been coincidentally discussed on a
> private list that I run.
>
> One thing that we thought was a good idea was to have a site salt. This
> salt
> would be applied in the same way (and in addition to) as the password
> specific
> salt. The point is that this salt is NOT stored with/in the password hash=
,
> it should not
> be stored in the database at all - thus making a cracker have to do more
> than
> steal the database of encrypted/hashed password records.
>
> There needs to be a way of specifying this, perhaps the array() to
> password_hash() could take an (optional) 'sitesalt' member that would be
> applied
> if it were present.
>
> Slight complication: since it is nice to be able to change the site salt
> occasionally, the user/password record would need to contain a column
> 'siteSaltVersion' this would be a simple number that is incremented every
> time
> that the site salt is changed. This would allow old passwords to be
> checked and
> (probably) silently re-encrypted/hashed the next time that the user logge=
d
> in.
>
>
>
> Also: the RFC (or final documentation) should state how long the returned
> string
> will be, so that the programmer knows how big the database_column/whateve=
r
> that the returned string is stored in should be.
>
>
https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--e89a8ff255c01f889004c85585f0--