Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62574
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain phcomp.co.uk designates 78.32.209.33 as permitted sender)
Date: Tue, 28 Aug 2012 16:55:36 +0100
To: internals@lists.php.net
Message-ID: <20120828155535.GR32129@phcomp.co.uk>
Mail-Followup-To: internals@lists.php.net
References: <CAAyV7nFRT24rksh6iDWxstfQwJ4+KdEC7Zs6EC8wBtJ8Zorf7w@mail.gmail.com> <CAAyV7nGbRzb5sMs3N7uz51d1c-2-2n51jfWYhZncstTv0GAtbA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAyV7nGbRzb5sMs3N7uz51d1c-2-2n51jfWYhZncstTv0GAtbA@mail.gmail.com>
User-Agent: Mutt/1.4.2.2i
Organization: Parliament Hill Computers Ltd
Subject: Re: [PHP-DEV] Re: [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
From: addw@phcomp.co.uk (Alain Williams)

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>