On Tue, Aug 28, 2012 at 5:55 PM, Alain Williams <a...@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 brief
> > > 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 else
> > 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 logged
> 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/whatever
> that the returned string is stored in should be.
>
>
https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Reply via email to