Password (re)hashing behavior and algorith verification

[jnoordsij]

In the Laravel skeleton, the verify configuration option has been set to true by default in laravel/laravel#6258. When trying this within my own application, I quickly ran into some trouble with some users that did not have their password changed for a long time, given that we previously used a different hashing algorithm. Altough this is exactly the goal of this feature, it made me wonder if the current configuration is a reasonable default going forward.

The biggest problem in my eyes with the current default values is that, if one decides to change hashing algorithm for some reason, the user-facing behavior is confusing: rather than the exception resulting in a failed authentication attempt, the user are shown the 500 error-page given the exception is unhandled.

I do admit that changing hashing algorithms is something that should only be attempted with much care and thought, so there's much to say for keeping things as is. However, I'm wondering if there can be any consensus in alternatives that might be slightly more user- and developer-friendly.

Possible enhancements:

• Altering the thrown exception to ensures it is handled and automatically converted into an authentication failure; this would prompt user to e.g. try to recover their password and properly obtain a correct hash in the process; however, this makes the issue less visible to developers. Or maybe even some more specific exception notifying users of an "expired" password.
• Given that [11.x] Rehash user passwords when validating credentials #48665 allows for rehashing, maybe some sort of graceful algorithm check failure could be made, that would allow rehashing between algorithms for some specific picks. (I do admit this does sound somewhat complicated and definitely is somewhat contradicting to what algorithm verification tries to achieve).

I'm very much just looking to see if there's any interest into changing the default Laravel behavior; if not that's also ok and I'll stick to finding a suitable solution just on my end.

[valorin]

Good question - that's definitely a use case we'd want to support. There needs to be a way to migrate between hashing algorithms.

My understanding is the hash verify flag is there to stop hashes from different algorithms from being verified - which would occur as part of the rehashing process.

If you set this to false, does it stop the error and allow rehashing to occur into the new algorithm?

It would make sense to me that to initiate a migration between algorithms, you'd need to set verify=false to allow it to support both algorithms and then update the algorithm config to the new one and the system would then migrate the passwords during login.
Is this possible, or am I missing something?

[jnoordsij]

Thanks for writing back!

Yes, that use path currently does work indeed. However, thinking about a little more, I think there's two potential issues I see in that:

1. After setting the value to false when you pick a new algorithm and let your users seamlessly migrate towards it, there's no real point where you can easily turn back;
2. This probably will make the process of changing your algorithm harder for the average developer, given you need to be aware of the fact that you do not only need to alter the algorithm itself, but also turn off the respective flag. This seems like a slightly obscure and possible unneeded additional barrier, which might make people hesitate to proceed with it.

To go a little further, I was wondering what the benefits of enabling this by default are at all. Altough laravel/laravel#6258 mentions it as a sensible default, I think there's a few downsides and potential confusion coming with it as I explained here, and I can't really think of any immediate/obvious pros to this new default.

[jnoordsij]

Resolved by #50718 and laravel/docs#9538.