- How do I install and register schuppo/password-strength in Laravel?
- Install it with composer require schuppo/password-strength. On Laravel 5.5 and later the service provider is auto-discovered; on older versions you must register it manually in config/app.php. Optionally publish the package config with vendor:publish to adjust thresholds and messages. After that, add the rule to the rules array of your FormRequest.
- Which Laravel and PHP versions does schuppo/password-strength support?
- The package was originally built for Laravel 4, and its last release is dated 2023-03-06, so its tested compatibility with PHP 8.2/8.3 and Laravel 10/11/12 is not publicly confirmed. Inspect the composer.json constraints and the CI matrix before adopting it. Treat Laravel 8 through 10 as the realistic target and verify behavior in your own test suite.
- What does the password score threshold mean and how do I configure it?
- The rule returns a strength score from a pluggable estimator such as zxcvbn, and you set a minimum acceptable score in the package configuration. Inputs scoring below that threshold produce a validation error. The exact boundary semantics depend on the configured estimator, so test the cutoff with representative weak and strong samples before relying on it in production.
- Does this package check passwords against Have I Been Pwned or common password dictionaries?
- No. It does not ship a native HIBP or breached-corpus check; it is a strength-estimation rule rather than a breach-screening one, and it may rely on character-class arithmetic rather than a dictionary list. Laravel's own Password rule with uncompromised() provides k-anonymity Have I Been Pwned lookups. If breach screening is a requirement, add it separately from this validator.
- How does schuppo/password-strength compare to Laravel's built-in Password rule and zxcvbn-php?
- Laravel's Password::defaults() with ->uncompromised() and the zxcvbn-php library are generally stronger modern defaults. This package is a Laravel 4-era composition or entropy-style validator with a small community footprint, roughly 143 stars and no dependents. It is a distant third choice on merit for greenfield projects, though it can help retire bespoke regex rules in existing applications.
- Is the package still maintained, and what happens when Laravel ships a new major version?
- It is a single-maintainer package with a 2023-03-06 release, so maintenance risk is real for something sitting in the authentication path. If the maintainer stops, the package can become a blocker on your next PHP or Laravel upgrade. Keep an internal exit plan and wrap the rule in an application-owned class so you can swap the engine without touching call sites.
- How do I customize the password validation error messages and translate them?
- Messages follow Laravel's standard validation conventions, and you can customize them through the package config and lang files, but verify translatability through the standard lang/ pipeline for your version. The most maintainable approach is to pass your own message on the rule instance inside the FormRequest. Avoid hardcoding user-facing copy in controllers or views.
- Can I use it in FormRequests and API validation, and does it fail open or fail closed?
- Yes, it is a standard validation rule, so it works in FormRequests, inline $request->validate() calls, and JSON API endpoints the same way. Whether it fails open or closed on unexpected input types depends on the rule implementation and the configured estimator, so test nulls, arrays, and non-string payloads explicitly. Always pair it with required and string rules.
- Does the package log or persist plaintext passwords anywhere?
- Passwords pass through the validator in plaintext, as they do with any strength rule, so confirm by reading the source that it does not log, cache, or persist the value. Also check that exceptions do not echo the input into stack traces or error responses. Keep validation messages generic so password fragments never leak into logs.
- Should I adopt this package for a new project or an existing Laravel app?
- For greenfield work, prefer Laravel's Password::defaults() with uncompromised() or zxcvbn-php; this package is only worth evaluating in existing Laravel 8 to 10 applications with bespoke regex rules to retire. If you adopt it, do not call the rule directly from FormRequests; create an App\Rules\PasswordPolicy wrapper that delegates to it. That wrapper is the real deliverable, giving you one place to change thresholds, add breach-list checks, and swap the engine later. Migrate one form at a time behind a feature flag.