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. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
