> On 31 Mar 2015, at 20:49, Anthony Ferrara <ircmax...@gmail.com> wrote: > > All, > > Ever since we introduced password_hash() in 5.5, I've been watching > its usage as much as possible. I've setup google alerts and such, as > well as auditing implementations I've found on github to try to > understand how it's used. > > One thing has become abundantly clear to me: the salt option is > dangerous. I've yet to see a single usage of the salt option that has > been even decent. Every usage ranges from bad (passing mt_rand() > output) to dangerous (static strings) to insane (passing the password > as its own salt). > > I've come to the conclusion that I don't think we should allow users > to specify the salt. The crypt() API still exists if users have a need > to generate their own salt. Having it in the simplified API is simply > adding a risk factor without any significant justification. > > So I'd like to hear your thoughts about raising E_DEPRECATED when the > salt option is specified in 7.0, with ultimately removing the option > in a later version. > > Additionally, I know this is after the RFC freeze deadline, so if you > want to postpone the deprecation to 7.1, that's fine. I just think > it's worth discussion (and if there's consensus to put it in 7.0, then > great). > > Thanks, > > Anthony > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
+1 I'd even go as far as adding a big red warning about custom salts to the manual page. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
