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