Jonathan, On Tue, Jul 31, 2012 at 8:32 AM, Jonathan Bond-Caron <jbo...@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? > > >
