UserProvider classes do not handle hashes with a custom cost factor

[miclf]

This bug impacts Illuminate’s authentication system.

The DatabaseUserProvider and EloquentUserProvider classes use the \Illuminate\Contracts\Hashing\Hasher interface as a dependency, in order to compare hashed passwords with provided credentials.

The problem is that they use the hasher with all the options set to their default value. As a result, the cost factor (the ‘round’ option) is always equal to 10. If the application uses a different value, hashed passwords stored in the database are never matched and all authentication attempts fail.

I see two possible ways to handle this:

1. Allow user provider classes to accept hashing options. This could quickly become really messy.
2. Create an option in a configuration file (similarly to the cipher option in /config/app) and use that. Then it could also be used by the app to hash its user passwords.

Ideas welcome.

[jasonlewis]

What about being able to set the default rounds on the hasher itself as it looks as though the property already exists. That way you could set it once and forget it. Saves passing in the options array every time.

Hash::setRounds(10);

$app['hash']->setRounds(10);

[miclf]

Implementing this in a custom way would need:

1. A custom class extending the Bcrypt hasher, to add the setRounds() method
2. A new facade (optional)
3. Overriding default bindings in a hacky way

Plus, you would tie your app to a specific implementation, thus loosing the benefits of coding to an interface (the Hasher interface has no knowledge of a concept of ‘rounds’ and some implementations may not need it). It would also leak things that should stay internal to the class.

All of this sounds way too hacky for this particular feature, so I think we do have a valid issue here (even if @GrahamCampbell doesn’t seem to think so).

[jasonlewis]

At the moment it would require that, yes. That's why I suggest we add the setRounds method. A very simple PR.

Although yes that does tie your app to an implementation. Which isn't ideal.

[miclf]

@jasonlewis: done in #6605.

That said, I’m not entirely sure it would work as expected for the scenario discussed here. The hasher is bound to the IoC via a Closure and it seems to me that the instance used by the *UserProvider classes would be a different one than the instance which we would set the rounds number on…

[jasonlewis]

Yeah it would be. I didn't notice that.