Password Strength Bundle Laravel Package

Product Decisions This Supports

• Password policy design: Defines what "strong" means across signup, reset, and account-change flows — minimum length, character-class requirements, and rejection thresholds. This is a live product surface that directly shapes conversion at the registration step, support ticket volume from locked-out users, and overall security posture. Getting it wrong costs real money in both directions (weak passwords → account takeover; over-strict rules → abandonment and reset tickets).
• Build vs. buy vs. port: Establishes that password-strength validation is a commodity capability for a Laravel shop. The package is ~200 lines of validation logic locked to Symfony2's Validator component — the decision is "build," and this repo is the reference spec, not the artifact. Zero dependents and 28 stars confirm no ecosystem validation to justify procurement.
• Compliance alignment: A concrete input to any NIST SP 800-63B, SOC 2, or ISO 27001 review. Importantly, it reflects the older complexity-rule model (mixed case + digits + symbols). NIST now favors length floors plus breached-password blocklist checks — a gap this package does not close and a roadmap item we must address separately.
• Fraud and abuse reduction: Stronger password enforcement shrinks credential-stuffing exposure and lowers account-takeover incidents — a measurable input to security-ops cost and the risk register.
• Use-case fit: Viable only for a Symfony 2.x legacy estate. For a Laravel product it is a pattern reference for a ~1-day native build.

When to Consider This Package

Consider it only when all of the following hold:

• The target application is Symfony 2.x — this is a bundle with a DI extension and Symfony Constraint/ConstraintValidator wiring; it will not resolve or autoload in Laravel, Lumen, or Symfony 4+.
• You are maintaining a legacy Symfony codebase, not modernizing it, and need a dependency-free validator that already exists there.
• Your policy is deliberately complexity-based (character classes) rather than length- and breach-list-based.

Look elsewhere when:

• Framework mismatch: You are on Laravel 10/11. Laravel's native Password::min(12)->mixedCase()->numbers()->symbols()->uncompromised() covers this with a maintained, framework-owned dependency and breached-password checking built in. This alone disqualifies it.
• Maintenance and supply-chain risk: 28 stars, zero dependents, and a Symfony2 EOL base (Nov 2018) mean no security response path and no PHP 8 compatibility work coming. Security review will flag it as an unacceptable dependency in an auth path.
• Modern guidance: You need NIST 800-63B alignment, breached-password screening, or entropy scoring (zxcvbn-style). None are provided here.
• UX depth: You want real-time client-side strength feedback, not just server-side rejection.
• Any crypto or parsing responsibility: Dormant upstream is tolerable for ~200 lines of deterministic string checks; it is not tolerable for anything security-critical.

Bottom line: Do not adopt. Treat as prior art for a one-to-three-day Laravel-native rule.

How to Pitch It (Stakeholders)

To executives: This is a small, unmaintained Symfony2 password validator. It is not a candidate for our Laravel stack — installing it would add an orphaned third-party dependency directly inside our authentication path, and it encodes a password model NIST has since moved away from. Laravel already ships this capability, including breached-password checks, and it's maintained by the framework. Recommendation: do not buy or install. Standardize on Laravel's native Password rule. Estimated effort: under one day. Estimated avoided risk: a permanent, unpatched dependency in the one code path attackers care most about.

To engineering: The package is a Symfony2 Constraint + ConstraintValidator pair that scores a plaintext password via character-class heuristics — roughly 50–100 lines of preg_match and strlen, plus translation files, wired through the Symfony kernel. There is no service provider, no publishable config, and no illuminate/* dependency, so composer require will drag in Symfony 2-era components and give us nothing. The equivalent in Laravel is one rule chain: Password::min(12)->mixedCase()->numbers()->symbols()->uncompromised(), centralized via Password::defaults() so registration, reset, and account-change flows share a single policy. If we need richer scoring later (entropy, dictionary rejection, UI meters), spec a thin in-house service around a maintained library like bjeavons/zxcvbn-php rather than resurrecting this bundle. Action: fund a one-day spike to read the source and confirm the algorithm is naive composition counting; if so, close as "reference only," cite it as prior art in the new rule's header, and update the security standards doc. Instrument validation-failure rates after rollout to catch false rejections of strong passphrases, and audit error handlers so no plaintext lands in logs.