Pierre, > No, it is exactly one example out of many where changing values are a > real pain to deal with over the years. We should not have one.
While I completely see your point (and don't disagree with it in isolation), I also see the counter point of making it easy for people to use. Knowing anything about algorithms to force the common developer to make a choice between bcrypt and scrypt is unreasonable IMHO. It's an implementation detail that they should know, but most won't. Knowing the intricacies of the different algorithms is something even most senior devs (who are not active in security at least) don't understand. I'd rather present them best-case defaults, and let them make the decision to diverge from them. With that said, what about a compromise. What if we made the API: password_hash($password, $algo, array $options = array()) And instead of just making the users choose which algorithm to use, we provide a "moving" constant called PASSWORD_MOST_SECURE Which will be updated every major release (assuming there's an update to apply) or in extreme circumstances (a serious flaw is found in the current most secure algorithm, justifying a concern). That way, people don't have to worry about moving targets, because the core moves it for them as needed. But the choice has to be made. They aren't just relying upon the default. And the documentation surrounding it must indicate that if cross-platform interoperability is a concern, pick a standard algorithm such as bcrypt and use just that. So then, a basic call would be $hash = password_hash($password, PASSWORD_MOST_SECURE); It solves both problems, while still being reasonably easy... Thoughts? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
