Hi all, On Fri, Jul 18, 2014 at 4:38 AM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> We internalized the algorithms in 5.3.2 at least partially because the > system provided libraries were inconsistent at best (hence why many > but not all 5.2 systems don't support bcrypt, it depended on the build > of libcrypt you linked against). > > Please don't make us re-live this inconsistency... Especially when it > won't really solve the problem. > OK for me. I suggested to close the bug as 'wont fix' in first place. > Regarding password_verify() accepting crypt(), I consider it an > implementation detail that it works. I know the RFC specifies it, but > it specifies it not as a conceptual fact (that it will always be no > more than a reason to be there), but more as an explanation for what > it's currently doing. I would not rely on that fact. It may work > today. It may work tomorrow, but it shouldn't be documented as such > (as it's the complement of password_hash(), not the complement of > crypt()). > > > As far as I'm aware, the only reason for not marking crypt() > > E_DEPRECATED right now is for compatibility with external systems, and > > as far as those go, changing a default won't effect anything. > > I want to reinforce that point, because it's spot on the money: > > I think crypt should live on. password_hash should be the way new > systems are built, sure. But as you mention external systems, crypt > should be a standard way of interacting with them (heck, that's what > the lib was designed for). It shouldn't be a "if you're not using > password_hash(), you're doing it wrong". It's "password_hash() should > solve the majority of use-cases, but if you have a different need, > there are other options". > I agree. crypt() should be available as normal function. Anthony, do you have suggestion for removing 72 char restriction of PASSWORD_BCRYPT? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
