Laravel 10.42 introduced a new max method on the fluent password validation rule object. But why would you do this?
Way back in the day, if you stored plain text passwords in your database 🤢, you might have had a max password length to prevent someone from creating a password that was longer than the database field it was being stored in.
But these days, passwords are hashed into a fixed-length string. There is no database length consideration, so why would you ever stop someone from creating a longer (and more secure) password?
Password hashing in Laravel is done with bcrypt, and internally bcrypt has a maximum password length of 72 characters. Anything beyond that is truncated.
Check out this demo:
use Illuminate\Support\Facades\Hash;
$originalPassword = Str::random(72);
$originalHash = Hash::make($originalPassword);
$longerPassword = $originalPassword . "more-characters";
// this returns true, both passwords will be accepted
Hash::check($longerPassword, $originalHash);
Because of this possibly surprising behavior, it would be better to let the user know that their password is too long before it is hashed. In fact, this is the OWASP recommendation.
In the original PR for this feature, there is even discussion about having Laravel 11 set a max password length by default.
Here to help,
Joel
P.S. I learned about the OWASP recommendation from Stephen Rees-Carter, who has an excellent Laravel-focused security newsletter.