Password Strength Laravel Package

Getting Started

Install the package with Composer:

composer require schuppo/password-strength

For Laravel 4, add the service provider to app/config/app.php:

'Schuppo\PasswordStrength\PasswordStrengthServiceProvider',

On Laravel 5.5+ package discovery should register it automatically; if not, add the provider manually to config/app.php. As of v2.7 the package declares support for Laravel 10.x, so current installs should resolve cleanly on modern Laravel — but still check the installed version constraint against your app's framework version before upgrading.

Look first at the package README and the registered validator class in src/ to confirm the exact rule name and whether the installed version accepts a minimum-score parameter. The package is a thin Laravel wrapper around zxcvbn-style password scoring, so the important details are the rule name, the score threshold, and the validation message.

Your first use case should be registration:

$request->validate([
    'password' => 'required|confirmed|password_strength',
]);

This replaces hand-rolled regex complexity rules with a dictionary- and pattern-aware strength check.

Implementation Patterns

Registration and password reset. Apply the rule to both the registration form and the reset-password form. Keep confirmed alongside it so the two password fields match, and keep required so empty values do not reach the strength checker.

Form Requests. Centralize the rule in RegisterRequest, UpdatePasswordRequest, or a shared trait so registration, profile changes, and admin-created users all enforce the same policy:

public function rules(): array
{
    return [
        'password' => 'required|string|min:8|max:72|confirmed|password_strength',
    ];
}

Config-driven thresholds. If the installed version accepts a parameter such as password_strength:3, put the threshold in a config file rather than hard-coding it in every form:

'password' => 'required|confirmed|password_strength:' . config('auth.password_min_score'),

API endpoints. The rule works with JSON validation responses. Return the standard 422 payload and keep the same rule in API form requests so web and API policies do not drift.

Custom messages. Add a translation key such as password.password_strength in resources/lang/.../validation.php, or pass a messages() array from the Form Request. Keep the message actionable: “Choose a longer password or a passphrase” is more useful than “Invalid password.”

Pair with hashing, not replace it. The rule checks strength only. Always store Hash::make($request->password) and never persist the plain value.

Client-side UX. Use zxcvbn.js or a strength meter for live feedback, then keep this package as the server-side source of truth. Server-side validation alone gives users a poor experience because they only learn the password is weak after submitting.

User-specific scoring. zxcvbn scores more accurately when it knows the user's name and email. If the Laravel rule does not expose those inputs, either accept the generic score or write a small custom rule around bjeavons/zxcvbn-php and pass user inputs directly.

Gotchas and Tips

• Laravel 4 origins. The package began as a Laravel 4 validator. v2.7 added Laravel 10.x support, so the framework wiring is current, but still verify service-provider discovery and the actual rule name in the installed release rather than trusting the GitHub README.
• Parameter semantics vary. Some versions treat the rule parameter as a minimum zxcvbn score from 0 to 4; others may not accept a parameter. Confirm by reading the validator class or testing known weak and strong passwords.
• Scores are version-dependent. zxcvbn dictionaries and scoring change between releases. Do not assert exact scores in tests; assert pass/fail against representative weak and strong examples.
• Server-side only. The package gives no strength meter or feedback UI. Users see a generic validation error unless you add client-side feedback.
• Performance. zxcvbn is more expensive than a regex. Cap password length, especially for bcrypt (max:72), and rate-limit registration and reset endpoints.
• It is not a complexity checklist. It may reject P@ssw0rd1 and accept a long passphrase. That is intentional, but document the policy for users and support staff.
• Message key mismatch. If your custom message does not appear, check the exact rule name registered by the service provider and use it as the translation key.
• Testing. Use Validator::make in unit tests and feature tests for the endpoint. If you manually register custom rules, clear the validator between tests to avoid leakage.
• Extension point. For user-input-aware scoring, custom feedback text, or per-guard thresholds, wrap bjeavons/zxcvbn-php in your own rule. This package is thin enough that replacing it is usually easier than fighting its defaults.
• Maintenance risk. v2.7 confirms the package is still being updated for current Laravel (10.x), which reduces — but does not remove — the risk of a small, lightly used dependency. Watch for future framework releases outpacing support; for a new high-security application, consider using zxcvbn-php directly so you control scoring, user inputs, and feedback.
• Never log passwords. Ensure validation exception handlers and debug tooling do not dump the submitted password value.