Fallback Password Encoder Bundle Laravel Package

Technical Evaluation

What it is: A Symfony bundle that provides a stack of password encoders for authentication — a modern encoder plus one or more legacy encoders — so users with old password hashes can still log in and are transparently rehashed to the modern algorithm on successful authentication. This is a well-established migration pattern (old hash → verify → rehash), packaged as framework plumbing.

Architecture fit: Low for the stack described. Despite the framing, this is a Symfony bundle, not a Laravel package. It relies on Symfony's dependency injection extension and the security component's encoder factory wiring. Laravel has no first-class equivalent "encoder stack" extension point; Hash is driver-based, so adopting this literally is not possible. In Symfony the fit is moderate but competing with native features (see below).

Integration feasibility: Moderate-to-low.

• Symfony: Symfony 5.3 deprecated encoders in favor of password hashers and shipped MigratingPasswordHasher / iterable hashers natively; encoders were removed in 6.0. This bundle's viability depends entirely on which API generation it targets. If it predates the hasher API, it is only useful on older Symfony and will break on upgrade.
• Laravel: You would port the pattern (custom Hasher contract implementation or a manual dual-verify service), not the code.

Technical risk: High.

• Security-critical, effectively unaudited code. Password verification logic is not a place for opaque third-party dependencies.
• Adoption signal is near-zero: 6 stars, 0 dependents, score 0.06. Assume no upstream maintenance, no issue triage, and no security response.
• API drift: the Symfony encoder→hasher transition is a known breaking change; a bundle in this niche is likely stale.
• Correctness details matter: constant-time comparison, fail-closed behavior, and rehash-on-login persistence must all be verified in source, not assumed.

Key questions to answer before any decision:

1. Which Symfony and PHP versions are supported, and does it target encoders or hashers?
2. Which legacy hash formats/algorithms are supported out of the box, and is the verifier list extensible?
3. Does it use constant-time comparison? Does it fail closed on an unknown format, or fail open (auth bypass)?
4. Does it actually persist the rehash, and under what conditions?
5. Test coverage, CI status, last commit date, and release cadence?

TPM assessment: Treat this repository as a reference implementation of the pattern, not a runtime dependency. The package bet is unattractive at 0.06 with zero dependents; the idea is worth adopting using native primitives.

Integration Approach

Stack fit: Conceptually strong — "verify legacy, upgrade on login" is exactly right for user-table migrations. As a literal dependency it is a poor fit for Laravel and a questionable one for modern Symfony.

Recommended integration (Laravel):

1. Inventory legacy hashes: formats, algorithms, row counts, and distribution across active/inactive users.
2. Adapter per format: wrap each legacy algorithm in a verifier with a common interface.
3. Chain verifier: attempt the modern hash first, then each legacy verifier in order.
4. Upgrade-on-login: on legacy success, rehash with Argon2id (or bcrypt) and persist immediately in the same request.
5. (Optional) Lazy migration: opportunistically rehash on any credential-bearing request, not just login.
6. Instrument the fallback rate as a first-class metric; when it reaches zero, delete the legacy path.

Recommended integration (Symfony): Prefer native MigratingPasswordHasher with an ordered hasher list over this bundle. Only evaluate the bundle if you are pinned to a Symfony version where the native mechanism is unavailable — and even then, vendor/fork it.

Migration path & compatibility:

• Pin to an exact tag or commit; audit composer.json constraints against your framework version before anything else.
• Never big-bang an auth change. Dual-verify behind a feature flag on a canary cohort.
• Keep the legacy verifier code (or the old dependency) available for rollback until the fallback rate is zero for a full inactivity cycle (e.g., 90–180 days).

Sequencing (rough effort): inventory (days) → adapters (1 sprint) → chain + rehash-on-login (1 sprint) → canary and monitoring (ongoing) → legacy retirement (single low-risk cleanup). This is a 1–2 sprint effort regardless of whether you use the package, because the audit and adapters are the real work.

Operational Impact

Maintenance: Effectively self-owned. Zero dependents and 6 stars mean no upstream support; if you adopt it, budget for a fork, a security review, and periodic manual patching against Symfony releases. The maintenance cost of a small in-house implementation is likely lower than owning an abandoned dependency.

Support: No community, no SLA, no triage. Every question, CVE, and compatibility break routes to your team.

Scaling: Hashing is CPU-bound. The fallback path performs two verifications for every not-yet-migrated user, temporarily roughly doubling auth CPU cost for that cohort. Size login infrastructure accordingly and rate-limit the auth endpoint. Expect a long tail: dormant users only pay the fallback cost when they return, so fallback rate decays slowly and retirement is gated on inactivity windows, not a fixed date.

Failure modes to design against:

• Fail-open fallback — unknown format accepted as valid (auth bypass). Must fail closed.
• Silent lockout — a legacy format the verifier does not cover, with no recovery path, locking out a user cohort.
• Non-constant-time comparison — timing side-channel in legacy verifiers.
• Rehash not persisted — fallback cost never decays; users stay on the legacy path indefinitely.
• Framework upgrade breaks the encoder wiring — auth fails globally at deploy. Add an auth smoke test to CI and a post-deploy synthetic login check.
• Weak modern default — misconfigured cost/algorithm silently degrading new hashes.

Ramp-up: Understanding the pattern is fast (hours). Operating custom authentication code safely requires security-aware engineering, a threat-model review, and monitoring for three signals: fallback rate, auth failure-rate anomalies, and rehash-lag. Plan a named owner for the auth path; this is not a "set and forget" integration.

Bottom line for planning: budget it as a build-the-pattern workstream using native framework primitives, not as a dependency adoption. The 0.06 score and zero dependents make the package itself a net risk to an auth-critical path.