2012/6/18 Anthony Ferrara <ircmax...@gmail.com>: > > That's why the crypt() return format was designed. All of the options > that are needed to validate the hash (algorithm, cost parameter, salt, > etc) are fit right into the outputted string. > > I'd suggest that's what's done here. In fact, I'd make the functions > just a thin wrapper around crypt(). Basically, just where it sets sane > defaults that we can update every minor (or major) release (to > compensate for faster servers). It handles salt generation, error > checking, etc. > > Here's what I have in mind in php: https://gist.github.com/2949382 >
I like your idea to offer a wrapper of crypt() with a better API (actually I used this approach in the ZF2 project: https://github.com/zendframework/zf2/blob/master/library/Zend/Crypt/Password/Bcrypt.php). I think we should also support the user's salt as option and generate a random salt if not provided. For the random generation I suggest to use as first option the openssl_random_pseudo_bytes() that is considered more secure compared with mcrypt_create_iv($size, MCRYPT_DEV_URANDOM). I just wrote that changes here: https://gist.github.com/2949592 Regards, Enrico Zimuel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
