Re: [PROPOSED] password_hash RFC - Implementing simplified password hashing functions
| From: | Anthony Ferrara | Date: | Tue, 31 Jul 2012 13:25:19 +0000 |
| Subject: | Re: [PROPOSED] password_hash RFC - Implementing simplified password hashing functions | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-61891@lists.php.net to get a copy of this message | ||
Jonathan,
On Tue, Jul 31, 2012 at 8:32 AM, Jonathan Bond-Caron <jbondc@openmv.com>wrote:
> On Thu Jul 12 02:34 PM, Anthony Ferrara wrote:
> >
> > > https://wiki.php.net/rfc/password_hash
>
>
> -- password_hash()
>
> password_hash_rfc(string $password, int $algo, array $options = array())
>
> My personal opinion is the api should be:
>
> password_hash(string $password, string $secret = '', array $options =
> array());
>
> where $options['method'] = PASSWORD_METHOD_BCRYPT;
>
> Some people mentioned that the method/algorithm in should be the api? What
> was the problem if crypt() stores the actual method/algorithm in the hash?
>
> Using this api, we let crypt() should a random salt value and we pick our
> secret.
>
> Say you have:
> define('MY_HASHING_SECRET', 'hhtrg54~%$%4....long');
> $password = '1234';
>
> password_hash_rfc($password . MY_HASHING_SECRET, PASSWORD_METHOD_BCRYPT);
> password_hash($password, MY_HASHING_SECRET);
>
> Note here that in both cases we let crypt() generate a random salt that is
> different for every password and store in the password.
>
> But our 'secret' that is appended to every password is not stored in a
> database for example, it's in some ways similar to a private key.
>
Please see this section of the RFC:
https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper
> -- password_make_salt()
>
> I would remove the need for this function.
>
> I think it's important the api emphasizes the importance of keeping a
> 'secret' + has the added value that every password hash is different with a
> crypt() salt.
>
> Thoughts?
>
>
>