Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

password_hash("foo") returning false on 5.3.2-1ubuntu4.30 #90

Open
sneakyimp opened this issue Nov 7, 2015 · 7 comments
Open

password_hash("foo") returning false on 5.3.2-1ubuntu4.30 #90

sneakyimp opened this issue Nov 7, 2015 · 7 comments

Comments

@sneakyimp
Copy link

OK at a very inopportune moment, I learn that this third party library just doesn't work on one of my servers that badly needs these password hash functions.

my code:

require_once 'password.php'; // the password_compat library
var_dump(password_hash("foo", PASSWORD_DEFAULT));

the output:

bool(false)

BOOO! I'm pissed. The code seems to get all the way through the process until it gets to this point:

            $hash = $hash_format . $salt;
echo "hash is $hash\n";
echo "password is $password\n";
            $ret = crypt($password, $hash);
echo "ret is $ret \n";
            if (!is_string($ret) || PasswordCompat\binary\_strlen($ret) != $resultLength) {
die("returning false, string length is " . PasswordCompat\binary\_strlen($ret) . " whereas resultLength is " . $resultL$
                return false;
            }

I've no idea what's failing but it looks like the crypt function isn't holding up its end of the bargain. The output:

hash is $2y$10$4yM5nzUadsYLVf.TBcowte
password is foo
ret is $2zJyhpjk3l9E 
returning false, string length is 13 whereas resultLength is 60

What the heck?

@adduc
Copy link

adduc commented Nov 7, 2015

From the requirements:

This library requires PHP >= 5.3.7 OR a version that has the $2y fix backported into it (such as RedHat provides). Note that Debian's 5.3.3 version is NOT supported.

@tchalvak
Copy link
Contributor

tchalvak commented Nov 9, 2015

Heheh, this isn't exactly the library's fault, there was a lot of bugginess during the transition to get bcrypt that took some patching to get right.

So you definitely want to get the server updated to the very latest version of php 5.3 to get any chance of a good working bcrypt (not sure that php 5.3 even -has- security support any more), and probably want to upgrade to php 5.4 or php 5.5 or whatever if you can push for that.

@ircmaxell
Copy link
Owner

I'd argue it's Debian's fault for not backporting a serious security fix...

Also, 5.4 and 5.3 are both End-of-life. Suggest upgrading to 5.5 if possible.

@sneakyimp
Copy link
Author

I should have certainly checked the requirements more closely, but I was under the impression that Ubuntu might have made important security improvements to php5.3.3.

Perhaps there could be some kind of PHP version check so password_compat lets us know if our version of PHP isn't going to play nice? I tried rolling out a fix to our production machines using this library only to realize with the code in production that it wasn't going to work.

@ircmaxell
Copy link
Owner

@sneakyimp check out #10 which details why that's not possible...

@sneakyimp
Copy link
Author

Ugh. Ghastly mess.

@ircmaxell
Copy link
Owner

Yup. This is why I recommend people never use Distribution-provided PHP...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants