Hi Anthony, I'm not sure about the idea to have a specific SPL for password hashing. I like the idea to have a standard interface for that but maybe is enough just a set of functions. I see a valid argument to have a standard interface especially for the password_register_algo().
Enrico 2012/6/18 Anthony Ferrara <ircmax...@gmail.com>: > Enrico > >> 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). > > Yeah, crypt() is really nice, and offers a lot of good things out of > the box. It's just the salt generation and error handling that are a > pita... > >> I think we should also support the user's salt as option and generate >> a random salt if not provided. > > Yeah, that could be good. The only part we'd need to be careful of is > error checking the salt (correct length, correct format, etc). But in > general I like the idea... > >> 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). > > Well, the point wasn't to make a CS secure salt. We've already had > discussions on that (it's not needed, and can harm the system to try > to use CS salts). All salts need to be is unique (statistically unique > is usually good enough). If people really want to use a CS salt, they > should pass one in as the user-generated salt. But I'd really like to > voice my opposition to having this function default to CS secure salt > generation... > >> I just wrote that changes here: https://gist.github.com/2949592 > > Looks good to me otherwise. > > I expanded my original gist a bit to add in the ability to register > your own algorithm: > > https://gist.github.com/2949382 > > That way, existing projects that use things like PHPASS can register > their own handler, and move towards this (let the fallback happen in > password_validate instead of in user code). > > If we're going to go with this option (the series of functions), what > do you think of putting them under spl: > > \SPL\password_create() > \SPL\password_validate() > \SPL\password_register_algo() > \SPL\password_create_salt() > > Instead of doing it class based as was originally suggested? > > The reason for namespacing is that password_validate is used in the > wild (not by many: > http://www.koders.com/default.aspx?s=%22password_validate%28%22&search.x=0&search.y=0&la=PHP&li=*&scope= > ) > > Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
