0

I have tested the password_verify of PHP that does not verify correctly. I am using centOS and PHP version 5.3.3. I know the 5.3.3 version of PHP does not provide the password_hash function, so i have used the https://github.com/ircmaxell/password_compat

However, it is always to return true with different passwords when i verify it. Is my code has bug?

Here is my code:

    $password = 'k32AlGOPqvCzoh*Sp(Hdrr26]M=lQb00R&W=hew|-|([(03vp==A8%m?l=eA2^bs_|\qVV3WZ';

    $verify_pw = 'k32AlGOPqvCzoh*Sp(Hdrr26]M=lQb00R&W=hew|-|([(03vp==A8%m?l=eA2^bs_|\qVV3WZasdasdasdasdqweqa13123';

    $options = array(
                'cost' => 15
            );

    $hash = password_hash($password, PASSWORD_BCRYPT,$options);

    var_dump(password_verify($verify_pw ,$hash)); // always true
Jacky Shek
  • 953
  • 1
  • 11
  • 35
  • I don't think you'll find much random in password_verify() but if you really believe that there is a bug in the code then you create a [SSCCE](http://sscce.org/) to prove your assertion and post an issue on [github for the compatibility pack](https://github.com/ircmaxell/password_compat/issues), or a bug report on [bugs.php.net](https://bugs.php.net/) – Mark Baker Nov 25 '15 at 08:08
  • But it is really happen to me, that is very sad what i get. I know `password_verify()` should be work correctly, but still cannot figure it out what thing cause this happen at my level. Or i should provide more info. – Jacky Shek Nov 25 '15 at 08:30
  • bcrypt by design *always* give out different hash output, look at [this sof question](http://stackoverflow.com/questions/8467819/bcrypt-generates-different-hashes-for-the-same-input). or just try [this bcrypt calculator](https://www.dailycred.com/article/bcrypt-calculator). However, i wonder if your different password means different plain text or a same plain text that passed into bcrypt and spit out different output - please verify. also, notice several first characters in your hashes, it defines hash length and salts, [wiki](https://en.wikipedia.org/wiki/Bcrypt) had explained this. – Bagus Tesa Nov 25 '15 at 08:41
  • it return always true now after restart apache. – Jacky Shek Nov 25 '15 at 08:42
  • @Tezla I mean different plain text. I have tested calculator, but my bcrypt still always return true. – Jacky Shek Nov 25 '15 at 08:46
  • yes, i tried on [dailycreds](https://www.dailycred.com/article/bcrypt-calculator) it also returns true. i wonder if it caused by your password pattern. So far, i tried random words won't behave like this. **EDIT**: looked like it simply discard trailling characters in password, but will check correctly for character shift, replace, or insert - but not at the end of password. – Bagus Tesa Nov 25 '15 at 08:50
  • 1
    well, it stated in wiki that [Many implementations of bcrypt truncate the password to the first 72 bytes.](https://en.wikipedia.org/wiki/Bcrypt#User_input). tried to shorten your password, it works as expected. – Bagus Tesa Nov 25 '15 at 08:57

1 Answers1

2

The problem is not your code. Bcrypt has a string limit from 56 bytes e.g. 55 Chars

https://www.usenix.org/legacy/events/usenix99/provos/provos_html/node4.html

the key argument is a secret encryption key, which can be a user-chosen password of up to 56 bytes (including a terminating zero byte when the key is an ASCII string).

So your string gets truncated and is the reason why your password_verify returns allways true as the truncated strings are identical.

ins0
  • 3,918
  • 1
  • 20
  • 28
  • Thank you very much, therefore i need limit user characters length or use SHA-512 with sperating random salt. Am i right? – Jacky Shek Nov 25 '15 at 09:01
  • Internally the algorithm manages characters better so you can go to at least ``71`` characters in total. I don't know if SHA-512 has a similar behavior – ins0 Nov 25 '15 at 09:10
  • SHA-512 should do it, it'll make digest of the string. – Bagus Tesa Nov 25 '15 at 16:47