Jonathan,
On Tue, Jul 31, 2012 at 8:32 AM, Jonathan Bond-Caron <[email protected]>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?
>
>
>