Advanced Encoder Bundle Laravel Package

Technical Evaluation

Architecture fit. Unchanged, and v1.1.0 confirms it. FOSAdvancedEncoderBundle remains a Symfony2 bundle that registers a compiler pass and decorates security.encoder_factory so a password encoder can be chosen per user instance rather than per firewall. Laravel has no bundle system, no EncoderFactory, and no DI extension point this code can occupy. The release adds encoders (Bcrypt, PBKDF2) but does not add a framework-agnostic seam — the capability is still welded to Symfony 2.3-era security internals. composer require into a Laravel app still fails or, worse, resolves a stale symfony/security constraint and drags a parallel framework runtime in. The transferable asset remains the design idea: per-record algorithm selection behind a registry and lookup strategy.

Integration feasibility. Zero direct, unchanged. The new release actually reduces what little pull there was: Bcrypt is already a first-class Laravel driver (config/hashing.php), and PBKDF2 is reachable via hash_pbkdf2() or an existing community driver — so v1.1.0's headline feature is capability Laravel already had, in a form Laravel can already call. A native port remains a UserProvider-adjacent resolver (map users.password_algo → hasher driver) plus a rehash-on-success hook: a few hundred lines of first-party code, no dependency.

Technical risk. High and unchanged. The release is a minor patch to an archived, unmaintained 2014-era package (30 stars, 0 dependents) still targeting the long-removed PasswordEncoderInterface and PHP 5.x. Two details in the notes sharpen the read rather than soften it: (1) "when using Symfony 2.3+" and testing on PHP 5.5 / 5.6 place the supported envelope firmly in 2014–2015 with no movement toward PHP 7, let alone the PHP 8.1+ that every supported Laravel release requires; (2) HHVM was added to the matrix, a runtime abandoned and EOL since 2018 — an explicit staleness marker, not a compatibility credential. No security patches, no CVE monitoring, no issue triage, no PHP 8 path. Password hashing is a security-critical path; unmaintained code here is a risk class no velocity gain offsets. The opportunity score (10.46) against a package score of 0.18 remains a statement about the problem, not the artifact.

Key questions.

• Does the target system need per-instance encoders at all, or is this a legacy-migration artifact — are we genuinely verifying bcrypt, argon2, and a pre-2015 custom scheme concurrently?
• What is the real inventory of hash formats, and which are verifiable by Laravel's built-in drivers without custom verifiers?
• (New, prompted by v1.1.0) Do any legacy hashes use PBKDF2 with non-standard parameters — iteration count, digest, key length, salt encoding? A generic PBKDF2 encoder will not verify arbitrary legacy encodings, and the bundle's support does not imply byte-compatibility with our stored values.
• Which formats are weak enough that the correct answer is forced reset rather than verify-then-rehash?
• Is algorithm selection stored as trusted server-side data, or could it be influenced by user input (algorithm-confusion / downgrade)?
• Is there a regulatory or audit requirement pinning specific algorithms, favoring an explicit declarative registry over implicit detection?

Recommendation: unchanged — do not integrate. Harvest the pattern, implement it as a small first-party Laravel service, keep the dependency surface at zero. v1.1.0 does not alter this; it adds encoders Laravel already ships and a test matrix that argues against the package's currency.

Integration Approach

Stack fit. None at the package level; unchanged. The stack-fit question reframes as mapping per-user encoder selection onto Laravel's contracts: HashManager supports multiple named drivers via config/hashing.php, and Hasher exposes make, check, needsRehash, info. Per-user selection is a thin resolver returning the right Hasher for a given Authenticatable before check() — no framework extension, no third-party code on the auth path. v1.1.0's Bcrypt and PBKDF2 support maps to bcrypt and a custom PBKDF2 driver in config/hashing.php; nothing in the release changes that mapping.

Migration path. Do not port the Symfony wiring (compiler pass, factory decoration, security.encoder_factory). Port the contract: (1) an algorithm or credential-format version column on users; (2) a resolver mapping it to a named hasher; (3) verification through the resolver; (4) rehash to the current default on successful authentication, persisted in-request. Steps 2–4 are the bundle's actual intent and are cheaper to write fresh than to translate — and step 4 is where the new PBKDF2 support would have mattered, except Laravel needs no upstream help to implement it.

Compatibility. Unchanged and now explicitly dated. The supported envelope is PHP 5.5/5.6/HHVM against Symfony 2.3+; Laravel 10/11/12 require PHP 8.1+ and Symfony 6/7. No shim is worth building. For non-Laravel PHP services, the same resolver pattern works with password_verify() / password_hash() / password_needs_rehash() — for PBKDF2, hash_pbkdf2() with stored parameters — a more durable target than any framework abstraction. A Symfony service needing this today should use Symfony's native user-aware PasswordHasherFactory; upstream absorbed the capability years ago.

Sequencing.

1. Inventory — enumerate distinct hash prefixes/formats and counts; for PBKDF2 specifically, capture iteration count, digest, key length, and salt encoding, not just the algorithm name.
2. Decide — per format, verify-then-rehash vs. forced reset (prefer reset for weak, non-standard, or unsalted).
3. Build the resolver — config-driven driver map, algorithm stored server-side only, no user-controlled input in the selection path.
4. Dual-read rollout — deploy behind a flag; verify old formats, rehash to Argon2id/bcrypt on success.
5. Instrument — emit hash-format-at-login metrics to watch the tail drain.
6. Decommission — remove legacy drivers at residual zero or after force-reset; delete the branch.

Do not plan a big-bang table rehash — you cannot rehash without plaintext. Upgrade-on-login is the only correct mechanism, and the sequencing is built around that constraint.

Operational Impact

Maintenance. Owning a fork of an archived 2014 bundle means owning its dependency graph, its PHP 5.x compatibility layer, and its security posture indefinitely. The v1.1.0 notes make the shape of that burden concrete: maintaining PHP 5.5/5.6 and HHVM-era assumptions against a PHP 8.2+ estate is a modernization project you inherit by adopting, not a task the package does for you. A first-party resolver of ~200–400 lines is materially less to maintain and is testable in the existing suite. The fork is more expensive than the rewrite.

Support. None. Archived repo, no maintainer, no advisory feed, no upgrade guide. The release is a one-off patch with no ongoing commitment behind it — it does not signal revived maintenance, and there is no maintainer to escalate to. For a defect on the password-hashing path, blast radius is account takeover; an unsupported dependency there is an unacceptable support posture regardless of code size.

Scaling. Functionally negligible — encoder selection is an in-memory map lookup; cost is dominated by the hash computation itself (Argon2id memory parameters are the real capacity input). The scaling concern is organizational: the per-user hasher pattern lengthens the supported-format tail indefinitely unless decommission is enforced with a metric and a named owner. v1.1.0's addition of two more encoders is a reminder that such registries only ever grow upstream.

Failure modes.

• Algorithm not found / unmapped — user cannot authenticate; fail closed with a distinct, alertable error, never fall back to a default hasher.
• PBKDF2 parameter mismatch — stored iteration/digest/key-length differ from what the resolver assumes; verification silently fails. Validate parameters explicitly during inventory, not at first login.
• Silent fallback to weak hash — the classic registry failure; guard with a strict allowlist and a startup assertion that every configured driver is strong.
• Rehash write failure — successful login, no upgrade; log and meter it or the migration never converges.
• Algorithm-confusion / downgrade — if format selection ever reads user-influenced data, an attacker pins a weak verifier. Enforce server-side-only provenance.
• Lockout during rollout — dominant user-facing risk; mitigate with the flagged dual-read and a rollback that restores the prior verification path without a deploy.
• Abandoned-fork drift — a transitive dependency breaks on a PHP minor bump; most likely failure mode in practice, and entirely avoided by not adopting the package.

Ramp-up. Low for the pattern, moderate for the archaeology. Any engineer can build the Laravel resolver from framework docs in days. Real cost is the legacy-format inventory and the force-reset judgment calls — required either way, independent of this dependency. Adopting the bundle adds ramp-up (Symfony2 DI conventions, deprecated encoder API, PHP 5.x toolchain, HHVM-era test assumptions) while removing none.

Bottom line. Score 0.18 remains correct and v1.1.0 does not move it. The release adds Bcrypt and PBKDF2 encoders Laravel already provides and extends testing to PHP 5.5/5.6/HHVM — a compatibility matrix that dates the package rather than modernizing it. Its value to a TPM is as a documented statement of a real requirement: per-instance password encoders for heterogeneous credential stores, which Laravel satisfies natively in a few hundred lines of owned, tested, supported code. Budget the rewrite, not the integration.