Laravel Password Laravel Package

Getting Started

composer require unicodeveloper/laravel-password

Laravel 5.5+ auto-discovers the service provider. On older 5.x apps, add Unicodeveloper\Password\PasswordServiceProvider::class to the providers array in config/app.php, then publish the config so you can see (and extend) the blocklist:

php artisan vendor:publish --provider="Unicodeveloper\Password\PasswordServiceProvider"

First use case is registration. Drop the package's password rule onto your password field alongside the usual constraints:

$request->validate([
    'email'    => 'required|email|unique:users',
    'password' => 'required|string|min:8|confirmed|password',
]);

Where to look first:

1. config/password.php (published) — this is the dictionary of "dumb" passwords the rule rejects. Skim it so you know what it actually catches (top-N common passwords, keyboard walks, repeated characters, etc.). It is a static list, not a strength meter.
2. The rule class in vendor/unicodeveloper/laravel-password/src — confirm exactly how comparison is done (trimming, casing, whether it hashes the input before comparing).
3. php artisan tinker to smoke-test the rule against a handful of inputs before wiring it into a FormRequest.

No migrations, no storage, no hashing — the package is pure validation.

Implementation Patterns

FormRequest is the natural home. Keep the rule out of controllers so every entry point uses the same policy:

class RegisterRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'email'    => ['required', 'email', 'unique:users'],
            'password' => ['required', 'string', 'min:8', 'confirmed', 'password'],
        ];
    }
}

Cover every password-setting path, not just signup. The most common production gap is that registration is protected but these are not:

• Password reset (ResetPasswordController / Fortify / Breeze actions)
• Change-password screens for logged-in users
• Admin "create user" and "impersonate / set password" screens
• Social login linking where a password is optionally set
• Seeders and factory data used for QA (worth guarding so bad habits don't leak into fixtures)

Stack it, don't substitute it. The rule answers "is this in the dumb list?" — it does not answer "is this strong?" Pair it with length, confirmed, and on Laravel 8.6+ the built-in strength/breach rules:

use Illuminate\Validation\Rules\Password as StrongPassword;

'password' => ['required', 'confirmed', 'password', StrongPassword::min(12)->letters()->numbers()->uncompromised()],

Custom rule object (newer releases). If your pinned version exposes a rule class rather than the string alias, inject it into the rules array instead:

use Unicodeveloper\Password\Rules\Password as DumbPassword;

'password' => ['required', 'min:8', new DumbPassword],

Customise the message. Either override in resources/lang/en/validation.php under the rule's key, or pass a messages array to validate() / FormRequest::messages() so the copy reads like a product message ("That password is too common — pick something less guessable").

Testing. Assert the failure path explicitly so a future Laravel upgrade that silently drops the rule is caught:

$this->post('/register', ['password' => 'password', ...])
     ->assertSessionHasErrors('password');

$this->post('/register', ['password' => 'correct-horse-battery', ...])
     ->assertSessionHasNoErrors();

Gotchas and Tips

• Name clash with Laravel's own Password rule. From Laravel 8 onward, Illuminate\Validation\Rules\Password exists. If you mix string and object rules, alias your imports (use ... as DumbPassword) — otherwise you'll get confusing "not a valid rule" or type errors.
• It is a blocklist, not a policy. Passing it means "not obviously dumb," nothing more. Never let it replace min, confirmed, or uncompromised(). It also won't catch user-specific dumbness ([email protected] → john2024); add a custom check that compares the password against the email/name if that matters to you.
• Confirm the exact rule name in the version you install. The alias has changed across releases; if 'password' throws "validation rule does not exist," check the README for that tag and use the rule object instead. Pin the version in composer.json so this can't shift under you.
• Maintenance risk. Last release was 2020-12-30. Verify PHP 8.x and Laravel 9/10/11 compatibility before adopting. If it's incompatible, the fallback is trivial: copy the published dictionary into your own rule class and drop the dependency — the value is the list, not the wiring.
• Case and whitespace. Verify whether the rule lowercases/trims before comparing. PassWord or password slipping through is the classic false negative; normalise in your own rule if needed.
• Config cache. After editing config/password.php, run php artisan config:clear (or config:cache on deploy) — in cached environments your new banned entries won't apply.
• Extending the list. Append entries from your own breach export or support tickets directly to the config array; that's the intended extension point. Keep it sorted/unique if you grow it large.
• API responses. The failure lands on the password key like any other rule, so JSON clients get a 422 with errors.password. Make sure your SPA maps that key to the field rather than showing a generic "something went wrong."
• Localisation. The default message ships in English only; add a translation key for every locale you support or non-English users see an out-of-place string.
• Debugging. When a password you expect to be rejected passes, test in isolation — Validator::make(['password' => $pw], ['password' => 'password'])->fails() — before blaming your request pipeline. It's almost always the rule not being loaded (provider missing / config cached) rather than the comparison logic.