Bcrypt Bundle Laravel Package

Technical Evaluation

Framing correction (important): despite the "Laravel/PHP package" brief, perbility/bcrypt-bundle is a Symfony2 bundle, not a Laravel package. That distinction drives most of the assessment below.

Architecture fit. The package is designed around Symfony2's bundle model — a Bundle class, DI container service definitions (services.xml/yml), and kernel registration. Laravel has no equivalent extension point; you would not "install" this, you would extract its hashing classes and re-register them behind a Laravel service provider. That is a port, not an integration. Meanwhile the functionality it provides — BCrypt hash creation and verification — has been in PHP core since 5.5 (password_hash/password_verify with PASSWORD_BCRYPT) and is the default driver behind Laravel's Hash facade. The package is functionally redundant on any modern stack.

Integration feasibility: low. Three blockers stack up: (1) Symfony2 reached end-of-life in November 2018, so any transitive constraints, autoloading conventions (likely PSR-0), and container APIs are pre-modern; (2) the repository shows zero stars and zero dependents, meaning no field validation and no downstream consumers exercising it against current PHP versions; (3) adoption of a second, unmaintained code path for security-critical hashing when a maintained first-party path exists is a net negative even if it technically runs.

Technical risk: high, and concentrated in the security-critical dimension. Hashing code is exactly where you do not want an abandoned dependency. Open questions to answer before any further evaluation: What is the license and last commit date? Does it wrap PHP's crypt()/password_hash, or implement BCrypt in userland (the latter is a red flag for correctness and timing safety)? Does it use constant-time comparison? What are its composer.json PHP and Symfony constraints, and do they resolve on PHP 8.x? Is there a test suite, CI badge, or security policy? Any known CVEs or documented 72-byte truncation handling? Absent credible answers, the default posture is "do not adopt."

Bottom line: this is a legacy artifact of the pre-password_hash era, not a viable dependency for a new or maintained Laravel application.

Integration Approach

Stack fit: none for Laravel, marginal for legacy Symfony. For a Laravel target, the correct integration is not this package at all — it is Illuminate\Hashing\Hash (Hash::make, Hash::check, Hash::needsRehash), which already defaults to BCrypt and is configurable via config/hashing.php. For a Symfony target, the maintained equivalents are symfony/password-hasher or the Security component's BcryptPasswordHasher. In both cases the package is displaced rather than integrated.

Migration path: hash-format portability is the escape hatch. The one genuinely useful property here is that standard BCrypt output ($2y$, $2a$, $2b$ prefixes with cost and salt embedded) is portable across implementations. If an existing system has password rows produced by this bundle, they can almost certainly be verified directly by Hash::check() or password_verify() with no rehash and no forced password reset — provided an audit confirms the stored format is standard BCrypt and not a proprietary encoding or pre-hash transform. That audit is the gating step.

Compatibility. Expect friction on composer.json constraints (PHP 5.x-era bounds, Symfony 2.x pins) that will conflict with a modern Laravel/PHP 8 dependency graph. Autoloading may be PSR-0. If any code must be lifted, isolate it behind an interface rather than pulling the bundle in wholesale, so the dependency never enters the resolved graph.

Sequencing:

1. Inventory existing hashes and confirm the exact stored string format on a sample of rows.
2. Prove verification parity in a staging harness: same plaintext against native password_verify / Hash::check.
3. Swap the verification path to the native implementation behind a thin adapter; keep a legacy fallback only if step 2 fails.
4. On successful login, opportunistically rehash with Hash::needsRehash to normalize cost factors.
5. Decommission the bundle and remove it from the dependency manifest entirely.

Operational Impact

Maintenance. Zero. With no stars, no dependents, and a Symfony2-era codebase, upstream is effectively dormant. Any fork becomes yours to own, including security patches for hashing code — an unattractive permanent liability for a solved problem.

Support. No community, no vendor SLA, no evident maintainer activity. Escalation path for a defect is "read the source." Contrast with the native path, which is covered by PHP's release and security process and by Laravel's documented API.

Scaling. BCrypt itself is intentionally CPU-bound; cost factor, not implementation, governs throughput. This package offers no performance advantage over native hashing and may be slower if it is a userland implementation. If authentication volume is a scaling concern, the lever is cost-factor tuning and, for new systems, evaluating Argon2id (PASSWORD_ARGON2ID, supported by Laravel's hasher), not this bundle.

Failure modes to watch: silent incompatibility if stored hashes are not standard BCrypt (verification failures manifest as mass login outages); 72-byte input truncation if pre-hashing isn't applied; incorrect or non-constant-time comparison creating a timing oracle; composer constraint conflicts blocking unrelated PHP or framework upgrades; and abandonment risk if a security issue lands in BCrypt usage patterns with nobody upstream to patch.

Ramp-up. Negligible for engineers already on Laravel's Hash facade — the mental model transfers directly. Any time spent understanding this bundle's Symfony2 service wiring is pure overhead with no reuse value.

Recommendation: do not adopt. Treat the package as a migration source only, validate hash-format compatibility, and standardize on the native Laravel hasher.