Password Policy Bundle Laravel Package

Technical Evaluation

Verdict: This is a Symfony bundle, not a Laravel package. It cannot be installed into a Laravel application as-is. Its value to a Laravel-based roadmap is limited to the domain logic inside it — validation rules, history/expiry policy services — which would have to be lifted out and re-wired into Laravel's container, validation, and auth events. Treat this as "reference implementation / source of design," not a dependency.

Architecture fit

• The distributable surface is Symfony-specific: a DI extension, config tree, compiler pass, Symfony Form type, and Twig templates. None of that has a Laravel analogue; Laravel has no bundle/extension model, so the auto-wiring, config merge, and form integration are dead weight we would maintain without using.
• The genuinely portable part is the policy core: password history persistence, expiry evaluation, and strength/composition validation. That is small, self-contained logic — which is both good (cheap to port) and bad (cheap to rewrite natively).
• Persistence is the real architectural coupling: history and expiry require a store of prior password hashes plus a "last changed at" timestamp. Whoever owns that schema owns the feature; here that would be us, not the package.

Integration feasibility

Net: roughly 60–70% of the package's codebase is unusable in our stack, and the 30% that is usable is the 30% that is cheapest to write from scratch.

Technical risk

1. Adoption risk (high). 0 stars, 0 dependents, no downstream consumers. There is no evidence of production usage anywhere, no third-party review, no CVE history either way. We would be an early adopter of unvalidated security code.
2. Bus factor (high). Single-vendor package with no visible contributor base. Security-sensitive code with one maintainer and no stated disclosure policy is an ongoing obligation, not a one-time evaluation.
3. Provenance (medium). Release metadata dated 2026-10-21 does not reconcile with a normal review cycle; verify that the tag, the CHANGELOG, and the tested-version matrix actually agree before relying on the compatibility claim.
4. Version-floor inconsistency (medium). Description states PHP 8.2+; the repo's own contribution rules state a default target of PHP >=8.1. Confirm the real floor — it directly constrains which of our services can consume it.
5. Policy-correctness risk (medium, product-owned). Forced expiry and composition rules conflict with current NIST SP 800-63B guidance, which recommends length/blocklist checking and against periodic rotation. If the business requirement is "expiry because audit says so," fine — but we should be able to defend it, because the package makes the anti-pattern easy to ship.
6. Security-review debt (medium). Password history means storing material derived from credentials. That store is now in our threat model and our retention policy.

Key questions

• Is the requirement actually Symfony, or was this found by keyword search? If our stack is Laravel, why is a Symfony bundle on the shortlist at all?
• What is the real PHP floor, and is the Symfony 6.4/7.4/8.x matrix CI-verified or asserted?
• Does the history store persist full hashes, truncated fingerprints, or HMACs? Retention and purge story?
• Is there a security policy / disclosure channel, and who is the responding party?
• Does the business requirement mandate expiry, or mandate "a password policy"? The latter is satisfiable with Laravel's built-in Password rule plus a history check, at a fraction of the risk.
• Would we vendor a fork (we own it) or consume it as a dependency (upstream owns it)? This package is too small to justify a dependency relationship.

Integration Approach

Stack fit Poor as a dependency, acceptable as a design reference. Laravel already ships most of the value: the Password validation rule (min length, uncompromised check via HaveIBeenPwned, mixed case, numbers, symbols) covers strength and blocklisting. The only genuine gaps versus this package are history and expiry — two features, both of which are ~a table, a service, and a login hook.

Recommended path (in order of preference)

Given 0 stars and 0 dependents, Option C is not defensible in a review. Option A is also faster than B once you account for reading and adapting unfamiliar code.

Migration path (if Option A/B chosen)

1. Spike (1–2 days). Read the policy and history services; extract the actual rule semantics (thresholds, history depth, expiry comparison basis — wall clock vs. last-change timestamp, timezone handling). Output: a one-page spec of the behaviour we want, not the code we want.
2. Schema. password_histories (user id, hash or fingerprint, created_at), password_changed_at on users. Decide fingerprint-vs-hash before writing the migration — it is a one-way door for purge.
3. Policy service. Single injectable class exposing validate(string $plain, User $u): void and isExpired(User $u): bool. No framework coupling.
4. Enforcement wiring. Login listener to flag expired credentials; middleware on authenticated routes to redirect to a change-password screen and allow-list logout/support routes. This is the part the package does not do for us in Laravel and the part most likely to be underestimated.
5. Backfill / rollout. Nullable password_changed_at; treat null as "not expired" or "force change at next login" — a product decision, not a technical one. Ship behind a feature flag, ramp per-tenant.
6. Decommission. No upstream to keep in sync; delete the vendored directory once native tests cover the behaviour.

Compatibility

• PHP: 8.2+ per description (disputed); confirm before any vendoring.
• Laravel: any version shipping Illuminate\Validation\Rules\Password (8.x+) for Option A.
• Hash driver: bcrypt/argon2 both fine; if the app allows multiple drivers or rehash-on-login, history comparisons must use Hash::check against stored hashes, never string equality.
• Auth topology: multi-guard apps, API tokens, and stateless SPA sessions each need separate expiry enforcement points. The bundle's Symfony-event assumption does not translate; validate our own coverage explicitly.

Sequencing Spike → schema decision → policy service + tests → login listener → route middleware → rollout flag → docs/runbook. Do not start with the UI; the enforcement gap is the risk, the screen is the easy part.

Operational Impact

Maintenance

• If vendored: we own every line and every future PHP/Laravel upgrade of it. Low ongoing cost (small surface) but non-zero, and it will be orphaned code within two quarters unless it is tested and documented as first-party.
• If depended upon: upgrade cadence dictated by a single maintainer; the CHANGELOG/UPGRADING discipline suggested by the repo's own rules is a good sign but unverified against actual releases.
• No copyleft exposure (MIT), no attribution burden beyond the notice.

Support

• No community, no dependents, no known SLA, no evidence of a response process for security reports. Escalation for a hashing or policy bug lands on our team by default. Budget for that in the on-call model or do not ship it.

Scaling

• History table grows linearly with user count × password changes; at 1M users and one change per year that is negligible, but index on (user_id, created_at) and define a retention cap (e.g. last 5) rather than unbounded rows.
• Validation cost is one hash verify per password change — irrelevant. Expiry check is a timestamp read on the login path — irrelevant. No scaling concerns at our volume.
• The only scaling question is operational: a forced-expiry policy across a large user base produces a synchronized change-password spike. Stagger if the requirement allows.

Failure modes

Ramp-up

• One backend engineer, 1–2 days to read the package and produce the behaviour spec; 4–7 days to implement, test, and wire Option A including middleware coverage.
• Review cost: one security-minded reviewer for the hashing/retention decisions and the route-gating test — half a day, non-optional for credential-handling code.
• Product/legal: a short decision on expiry policy (NIST alignment vs. auditor expectation) and retention window. This is the item most likely to block the schedule, and it is not an engineering task.
• No training burden: the resulting code is ordinary Laravel validation and a listener. That is a point in favour of not adopting the bundle.