[5.6] rename bcrypt to hasher and allow null value

[browner12]

the helper, like the Facade, should be implementation agnostic. while we currently do use Bcrypt as our hashing algorithm, it is possibly it will switch to a more updated algo in the future.

also allow passing a null value to get the Hasher instance back. this pattern is used in many of the other helpers. this was originally sent as a separate PR to 5.5, but after a discussion with @Dylan-DPC it was determined this was a BC break.

[m1guelpf]

Reference: Add a str_hash helper, Return hasher when value is null, Rename bcrypt helper & Bcrypt changed to Hash::make and renamed to str_hash.

[sisve]

Can we keep the previous bcrypt helper method and mark it as deprecated in the spirit of laravel/ideas#383 ?

[taylorotwell]

It doesn't make sense to pass a string to a function named hasher.

[m1guelpf]

It doesn't make sense to pass a string to a function named hasher.

And that brings us again to the name problem...

[browner12]

definitely open to other names. I just don't think bcrypt is appropriate.

[Dylan-DPC-zz]

Yeah i would prefer if bycrpt() gets deprecated first before being removed.

[browner12]

even though I'm targeting Master?

BTW, I'll fix the tests if and when we get this discussion sorted out.

[taylorotwell]

To me there is no need to replace it with anything as we have Hash::make. If we were going to add any other I would think it would be something like Str::hash?

[browner12]

I mean, if we just want to go with the Facade, and drop the helper completely, I'm okay with that. Personally I use the helpers over the Facades, but that's me. I don't think adding Str::hash is necessary.

As long as we get rid of (or deprecate) the bcrypt helper, because technically the Hasher could be set up to use any different algorithm. Especially with all the new things in 7.2, I'm guessing password hashing will see a little bit of a shakeup soon.

[paulofreitas]

Alternate names:

encode_password() (taken from Symfony/Silex)
password_digest() (taken from Ruby/Python where digest is a synonym to hash)
hash_password() (I guess this would make a lot of confusion with PHP password_hash())

In the near future we would probably have a new Argon2 password hasher. I think that the Illuminate\Contracts\Hashing\Hasher contract would be better called PasswordHasher instead. Similarly, the Illuminate\Hashing\BcryptHasher class would be better called BcryptPasswordHasher.

Having more than one password hasher implementation I think that we could use some config to instrument the password hashing algorithm being used by both the Hash::make() and helper methods. Something like a 'password_hashing' => BcryptPasswordHasher::class in the config/app.php configuration file. 😃

[m1guelpf]

@paulofreitas If you name the helper like that, you're implying it'll be used to hash a password, which could not be the case... Same with PasswordHasher.
Also, encode_password looks insecure (encoding and encrypting/hashing are diffierent things).
If we're going to keep the helper, I'd suggest str_hash or hash_make.

[paulofreitas]

@m1guelpf PHP itself use the password_hash() and password_verify() names. Actually it's using password_hash() internally and the whole point of the hashing functionality is to create strong password digests. To just hash things we have the PHP hash() function. 😄

[taylorotwell]

I don't think we really need a Str::hash and we'll evaluate removing or deprecating this when we actually do have an alternative hasher out of the box.