I think it is bad to require 17 bytes of entropy for the salt, when only 16 bytes are needed. The underlying bcrypt function in crypt expects only 128 bits in the salt.

I generated a 6 digit passcode for a users password using mt_rand this returned an int, when it comes to hashing the int it errors.

https://github.com/ircmaxell/password_compat/blob/master/lib/password.php#L31

Refactored the methods into a HashPassword class for better code organization when using OOP in projects.

$pwObj = new HashPassword(); $hashedPasswd = $pwObj->password_hash($passwd, PASSWORD_BCRYPT, ["cost" => 10]); echo $hashedPasswd;

These changes add support for sha512 hashing algorithm. This is often required for compatibility with applications that don't support bcrypt.

I am far from an expert on this level, but these changes work fine on our setup. What are your thoughts?

Hello, I just implemented this excellent library (thanks for creating it) a few days ago.

Now I got a report from a developer using PHP 5.3.8-ZS5.5.0 (cli) - which is perfectly matching the requirements - that password_hash returns false instead of a hash.

Seems like crypt() function reported a failure, but I have no clue how to find out why. Testing the same against PHP 5.3.14 works without any problems.

Any idea ?

The function doesn't output the same hash as PHP 7.2.

PHP 5.3.10 using this function $hash = password_hash('mypassword', PASSWORD_BCRYPT, array('cost' => 10)); $hash is $2y$10$mdrfl9XUF9J/qe2wnxopNevC1HtAcVxmYz9JSoetyABJggR7aMmNe

PHP 7.2.24 calling native password_hash() $hash = password_hash('mypassword', PASSWORD_BCRYPT, array('cost' => 10)); $hash is $2y$10$HV3YTr/Mg2KvijZzUz9VDet.dlLbeKqToYHhodFCnCURgZVz.VEy2

Am I missing something?

Hi,

I'm just wondering whether this repo is still being actively maintained by its owner? I'd been recently considering trying to implement something like what this package is intended to do, and it seems like package could be quite useful, but I can see four open pull requests to this repo currently, the oldest open since 2013 and the newest since 2015, and a number of forks with commits made since after the last commit to the parent; Not sure whether it would be better to work directly from the parent, from one of the forks, or something else.

Your input appreciated, and cheers. :-)

The documentation says that the hash of password_hash should be passed as hash parameter to password_verify. It does not say anything about the result when this value contains something else.

I store the result of password_hash in a database and check it against a password later on (as documented). But if the password is not initialized, an empty value is passed to password_verify. The verification fails as crypt() makes up its own salt, but that was for this particular case.

Are there any guarantees on the validation result when the hash is not exactly a return value of password_hash? (note that the password argument can be anything as this is passed by the user)

Hello,

I'd like to know when the next tagged release will be? Your last tag is from over a year ago and there are some fixes that I'd like in production.

Thanks!

Removed use of type-juggling comparison operators. The type-comparing comparision operators are safer to use in a security-sensitive code and faster [1].

[1] http://stackoverflow.com/questions/6356826/comparing-versus

altough it states that returns false on error, most of the error checks return null instead, so a " === false " comparison would fail. also, it is inconsistent with password_verify that returns false on "crypt missing" error

Hi all,

This is just a "service message".

For those people who use this library and use PHPCompatibility in their CI process, there is now a custom ruleset available which can be used to prevent false positives being thrown by PHPCompatibility for the native PHP functionality being polyfilled by this repo.

You can find the repo for the PHPCompatibilityPasswordCompat ruleset here on Github as well as on Packagist.

• https://github.com/PHPCompatibility/PHPCompatibilityPasswordCompat
• https://packagist.org/packages/phpcompatibility/phpcompatibility-passwordcompat

Hope someone will find it useful :smile:

P.S.: If anyone is interested in helping us to maintain the ruleset, please open an issue in the repo.

105 | ERROR | Function mcrypt_create_iv() is deprecated since PHP 7.1 and removed since PHP 7.2; Use random_bytes() or OpenSSL instead 105 | ERROR | Extension 'mcrypt' is deprecated since PHP 7.1 and removed since PHP 7.2; Use openssl (preferred) or pecl/mcrypt once available instead 105 | ERROR | The constant "MCRYPT_DEV_URANDOM" is deprecated since PHP 7.1 and removed since PHP 7.2

When I run the following code in PHP 5.4.45

$password = 'XXX';
$salt = 'XX';
var_dump(password_verify($password, crypt($password, $salt)));

I get false as result. When I run the same code with PHP's native password_verify function, I get true

This should be pretty easy to do, since PHPUnit does support *.phpt format. All that is needed is to copy them from php-src and add

--INI--
auto_prepend_file=lib/password.php

to each test file.