Scrypt Password Encoder Bundle Laravel Package

Technical Evaluation

Architecture fit. This is not a Laravel package — it is a Symfony2 bundle (usu/scrypt-password-encoder-bundle), and the distinction is disqualifying at the architecture level. The distribution is mostly Symfony plumbing: a Bundle subclass, a DependencyInjection extension, service/parameter definitions, and a security encoder factory wired into the Symfony security.encoders config. Laravel exposes none of those extension points. It uses a service provider + Illuminate\Contracts\Hashing\Hasher binding through HashManager, configured via config/hashing.php. The genuinely reusable surface area is roughly one class that wraps the PHP scrypt() function (ext-scrypt, a PECL extension). Everything else is dead weight in a Laravel context.

Integration feasibility. Low, but not zero. A Laravel-native equivalent would be a single class implementing Illuminate\Contracts\Hashing\Hasher (make, check, needsRehash), registered via Hash::extend() in a service provider. That is on the order of 100 lines of work. The problem is that you would be authoring and owning that class rather than consuming the package — the package itself contributes no runnable code path under Laravel.

Technical risk. High, on multiple independent axes:

• Dependency resolution. Composer constraints are pinned to the Symfony 2.x era (2014). They will not resolve against any supported Laravel release (5.x through 11.x). Installation fails before runtime.
• Platform risk. scrypt is not in PHP core. It requires ext-scrypt, an effectively dormant PECL extension with no PHP 8.x support story. Modern runtimes (php:8.1-fpm, Alpine, distroless containers) will not have it, and building it is a supply-chain and maintenance liability.
• Abandonment. Last release 2014-11-29, 18 stars, 0 dependents, no CVE-watch, no CI signal. Password hashing is precisely the component where a stale dependency is least acceptable — it is the highest-consequence code in the stack.
• Security posture. scrypt is a legitimate memory-hard KDF, but Argon2id is the current OWASP recommendation, is native in PHP 7.2+, and is a first-class Laravel driver (Hash::driver('argon2id')). Adopting an 11-year-old wrapper to obtain scrypt is a net security regression versus the framework default.
• Unknown test coverage. No evidence of a test suite, so a port has no behavioral baseline to port against — you would be reverse-engineering intended semantics.

Key questions.

1. Is there a compliance or interop mandate for scrypt specifically, or is this a preference that Argon2id satisfies?
2. Does the production users table already contain scrypt hashes that must be verified (not generated)? If yes, this becomes a bounded legacy-verification task, not a package adoption.
3. Which Laravel and PHP versions are in scope? (If PHP ≥ 7.2, Argon2id is available with zero dependencies.)
4. Is ext-scrypt installable in the target runtime, and is the team willing to own that build indefinitely?
5. What is driving the evaluation — a real gap in HashManager, or incidental discovery of the package?

Integration Approach

Stack fit. Poor. Symfony2 bundles and Laravel packages are structurally incompatible: no composer.json extra.laravel providers, no config publishing, no facade binding, no HashManager driver registration. Nothing in the package auto-wires in Laravel, and the framework-agnostic core is too thin to justify the extraction.

Migration path. Three options, in order of preference:

• Option A — Do not integrate (recommended). Configure Laravel's native hasher as argon2id in config/hashing.php, tune memory / time / threads, and rely on Hash::make / Hash::check / needsRehash unchanged. Zero new dependencies, native support, upgrade-safe across Laravel majors. This resolves the underlying need (memory-hard password hashing) without the package.
• Option B — Legacy verification only. If scrypt hashes exist in production, write a verify-only custom hasher bound with Hash::extend('legacy-scrypt', ...), implement needsRehash() to always return true, and let Laravel's Hash::check rehash to Argon2id on successful login. Back it with a maintained scrypt implementation, not ext-scrypt, and gate it behind a driver selection routine that only routes pre-migration rows to it.
• Option C — Port the bundle. Rewrite as a Laravel service provider. Technically straightforward (~1–2 days), but it produces a bespoke fork of an abandoned repository with permanent ownership cost and no upstream to rebase against. Only justified if options A and B are both blocked.

Compatibility. Composer will not resolve Symfony 2.x constraints against Laravel 5.5+. PHP version constraints predate 8.x. ext-scrypt is unavailable on modern PHP. Treat the package as non-installable and plan accordingly — do not budget time for fighting the resolver.

Sequencing. (1) Inventory hash formats actually present in the users table — this is the decisive input. (2) If no scrypt hashes: close the evaluation, document Argon2id as the standard, move on. (3) If scrypt hashes exist: ship the verify-only driver, verify against a production-shaped sample, enable rehash-on-login, and instrument rehash coverage. (4) Once rehash coverage reaches threshold (or a forced-reset window passes), remove the legacy driver and dependency entirely. (5) Add a CI assertion that only approved hasher drivers are configured.

Operational Impact

Maintenance. Effectively unmaintainable upstream: no commits since 2014, no maintainer responsiveness, no security disclosure channel, no dependents to surface breakage. Any adoption converts into a permanent internal fork — you own the code, the PECL build, and the CVE response. Contrast with Argon2id, where PHP core and Laravel own that burden.

Support. No vendor, no community, no current documentation beyond a 2014 README. Knowledge concentrates in whoever performs the port, which is a bus-factor risk on the most security-sensitive code path in the application. Debugging will require reading Symfony2 DI conventions that no one on a modern Laravel team routinely touches.

Scaling. scrypt is intentionally memory-hard, and that cost lands on the request workers. With naive parameters (N=2^14+ at r=8), each hash consumes tens of megabytes; a login burst or credential-stuffing attempt becomes a memory-exhaustion event against PHP-FPM pools sized for typical web traffic. Parameters must be tuned against memory_limit and pool concurrency, and auth endpoints need rate limiting and load testing before launch. Note that this risk applies to scrypt generally, not just this package — but the package gives no ergonomic way to tune it, whereas Laravel's Argon2id driver exposes memory_cost declaratively in config/hashing.php.

Failure modes.

• Install-time: Composer conflict on Symfony/PHP constraints — hard failure, caught early.
• Boot-time: missing ext-scrypt throws at container resolution, taking the app down rather than degrading one feature.
• Auth-time: parameter drift between hashing and verification silently locks out every user with no clear error surface.
• Schema: scrypt output exceeds common VARCHAR(60) bcrypt-era column widths; truncation produces intermittent, hard-to-reproduce login failures. Requires VARCHAR(255) and a migration.
• Comparison: a 2014 implementation may not use a timing-safe comparison, introducing a side channel that no standard test suite will catch.
• Rehash gap: without needsRehash, legacy scrypt hashes persist indefinitely, defeating the purpose of the migration.

Ramp-up. The code surface is small — one encoder class plus Symfony wiring — so reading time is a day at most. The real cost is archaeology: reconstructing Symfony2 DI semantics, standing up a PECL extension in the build pipeline, and writing the test suite the package never shipped in order to establish a behavioral baseline before touching production auth. Budget 1–2 engineering days just to reach a go/no-go, plus indefinite ownership if the answer is go. Against roughly zero incremental effort for native Argon2id, the trade is unfavorable.

Recommendation. Reject. The 0.21 score is consistent with the findings: framework mismatch, eleven years of abandonment, zero dependents, and a platform dependency that does not exist on modern PHP. The underlying requirement — memory-hard password hashing — is fully satisfied by Laravel's built-in argon2id driver. Reserve engineering effort only for Option B if and only if production data proves legacy scrypt hashes exist, and scope that work as a time-boxed migration with a defined decommission date.