[ISSUE] Integers aren't "strings" so exception is thrown. about password_compat HOT 10 CLOSED

If you want it to be a string, cast it to a string:

$hash = password_hash((string) $your_number, PASSWORD_DEFAULT);

This is not a bug.

from password_compat.

Ok it isn't a bug but if your going to make a fallback for PHP 5.5 and it works as an int in PHP 5.5 surly it should work in the fallback.

from password_compat.

Oh right, it does not fail in the PHP 5.5 implementation. Then it is probably an undocumented feature / bug.

from password_compat.

The real bug is on your part and consists of using mt_rand() to generate passwords. This function is completely unsuitable for security applications, because the output is drawn from very few sources and can potentially be predicted. The range of numbers is also extremely small. Usually, it's only four bytes!

You definitely need to stop doing this and instead use an appropriate random number generator like mcrypt_create_iv() or openssl_random_pseudo_bytes().

There's a very good reason why the function expects a string. If the native API doesn't, that's what needs to be fixed.

from password_compat.

Don't worry about the security of a temporary password, I'm not that foolish I wanted passwords but my boss wants 6 digits and even that was a push he wanted no authentication for the application needless to say something that works in PHP 5.5 should work in the fallback.—
Sent from Mailbox for iPhone

On Tue, Jan 28, 2014 at 6:33 PM, Jacques1 [email protected]
wrote:

The real bug is on your part and consists of using mt_rand() to generate passwords. This function is completely unsuitable for security applications, because the output is drawn from very few sources and can potentially be predicted. The range of numbers is also extremely small. Usually, it's only four bytes!
You definitely need to stop doing this and instead use an appropriate random number generator like mcrypt_create_iv() or openssl_random_pseudo_bytes().

There's a very good reason why the function expects a string. If the native API doesn't, that's what needs to be fixed.

Reply to this email directly or view it on GitHub:
#48 (comment)

from password_compat.

This could be trivially fixed using a (string) cast in this lib.

from password_compat.

The documentation of password_hash says that a string is expected. Pushing an integer into it makes no sense. Just ensure from your user application that a string is used.

from password_compat.

At the time my employer wanted a PIN number sent to their customers. It worked on my PHP 5.5 development machine but not when the end guys deployed it, if this is a fallback it should be exactly the same surly. You can type cast the given parameter to a string allowing a full coverage fallback.—
Sent from Mailbox for iPhone

On Sun, Aug 17, 2014 at 2:16 PM, Peter Wu [email protected]
wrote:

The documentation of password_hash says that a string is expected. Pushing an integer into it makes no sense. Just ensure from your user application that a string is used.

Reply to this email directly or view it on GitHub:
#48 (comment)

from password_compat.

Heh, in a user application where you're constraining the inputs, just adding a cast to string makes sense, but in a robust library transparency & granular-as-possible error reporting is key. Casting to a string in the library itself would probably end up tripping a lot of users up in annoying & hard to track down ways.

So I think this would be something best added to your private app-level implementation and have the library kept as simple and unsurprising as possible. Maybe it'd make sense to file an issue with the php.net implementation about it's duck-typing instead?

from password_compat.

@tchalvak Perhaps if this was a standalone library, but it's supposed to fill in for 5.5+'s password_hash. For that reason, it should exactly mirror its behaviour.

from password_compat.