Bcrypt Bundle Laravel Package

Getting Started

First, the mismatch. perbility/bcrypt-bundle is a Symfony2 bundle, not a Laravel package. There is no ServiceProvider, no facade, no extra.laravel block, and no Composer auto-discovery — composer require perbility/bcrypt-bundle in a Laravel app will at best pull in dead Symfony 2.x constraints and at worst fail resolution outright. If your goal is "hash passwords in Laravel," stop here: Hash::make() / Hash::check() (config/hashing.php, driver bcrypt, cost 12) already does everything this bundle does, is maintained, and is constant-time safe.

Where to look first (if you've inherited a Symfony2 app that uses it):

1. composer.json in the bundle — check the symfony/symfony constraint; anything ~2.x means PHP 5.3–5.6 era and you're looking at an unmaintained dependency.
2. Resources/config/services.xml / services.yml — that's where the hashing service ID is declared. That service is the entire package: a thin wrapper over PHP's crypt() with a $2y$ salt, exposing roughly hash($plain) and verify($plain, $hash).
3. DependencyInjection/ — a single extension class, no compiler passes worth noting.
4. The bundle class itself, registered manually in app/AppKernel.php:

// app/AppKernel.php
$bundles = array(
    // ...
    new Perbility\BCryptBundle\PerbilityBCryptBundle(),
);

First real use case: hash at registration, verify at login, before Symfony shipped its own BCrypt encoder. That's it — the package has one job.

The Laravel equivalent you should actually reach for:

$hash = Hash::make($request->password);          // bcrypt, cost from config
if (Hash::check($request->password, $user->password)) { /* ok */ }
if (Hash::needsRehash($user->password)) {         // cost/algorithm upgrade
    $user->update(['password' => Hash::make($request->password)]);
}

Implementation Patterns

If you are stuck maintaining the Symfony2 side, the sane patterns are:

• Inject, don't fetch. Type-hint the hashing service into your controller/service constructor rather than $container->get(...); the latter is untestable and hides the dependency.
• Wrap it behind your own interface. Define App\Security\PasswordHasher with hash()/verify(), implement it with the bundle service. When you migrate to Symfony's security.password_encoder (2.2+) or off Symfony entirely, you change one class instead of grepping for service IDs.
• Rehash-on-login upgrade. On successful verify(), check whether the stored hash matches your current cost ($2y$10$ vs $2y$12$ prefix) and re-hash transparently. This is the only clean way to raise cost without forcing password resets.
• Cost by environment. Production 10–12; test suite cost 4 so your feature tests don't spend 250ms per fixture.

If you are bridging hashes into Laravel (the realistic scenario — an old Symfony app whose users are moving to a Laravel app):

// The bundle emits standard $2y$ bcrypt strings.
// Laravel's BcryptHasher verifies them unchanged — no port needed.
if (Hash::check($plain, $legacyHashFromSymfony)) {
    $user->password = Hash::make($plain); // immediate upgrade
}

Because both sides produce $2y$-prefixed, 60-character, crypt-compatible strings, Hash::check() is a drop-in verifier. You do not need to install the bundle in Laravel just to verify its output.

Integration tip: if someone insists on the bundle in a mixed codebase, isolate it to a single adapter class and never let its service leak into application code. Treat it as a legacy data format, not a library.

Gotchas and Tips

Installation and compatibility

• The bundle's Symfony constraint will collide with anything modern. If Composer "succeeds" via --ignore-platform-reqs, you have a dependency you cannot run safely on PHP 8. Don't.
• No Laravel package discovery; even if it installed, you'd get a bundle class that Laravel never boots. There is no meaningful way to "use" this in Laravel.
• Abandoned: 0 dependents and 0 stars means zero downstream pressure to patch security issues. Assume it is frozen at its 2012-era behavior.

Hashing correctness

• 72-byte truncation. BCrypt silently ignores bytes past 72. Long passphrases collide at the 72-byte boundary — same password prefix, same hash. Don't advertise unlimited-length passwords.
• $2a$ vs $2y$ vs $2x$. Ancient crypt() implementations emit $2a$, the bundle likely $2y$. If you compare prefixes in your rehash logic, normalize first or you'll rehash on every login. Laravel accepts $2y$; both are fine for Hash::check().
• NUL bytes. PHP's crypt() had a null-byte truncation bug fixed in 5.5.21/5.6.5. On older PHP, any password containing \0 is a bypass vector. If you're running this bundle, you're likely on those versions — check phpversion() immediately.
• Failure returns. crypt() returns *0 or *1 on error, not false. A naive if (!$result) or == comparison is exploitable. Verify must use hash_equals().
• Never == a hash. String comparison leaks timing. This is the single most common bug in hand-rolled wrappers of crypt().

Operational

• Non-deterministic output. Same password, different hash every call. You cannot assert equality in tests, log-compare, or diff hashes in fixtures. Always assert via verify().
• Column width. 60 chars for $2y$ bcrypt, but store 255 — cost changes and future algorithm swaps will overflow a char(60).
• Cost is a DoS surface. Cost 14+ on a login endpoint is a free CPU exhaustion primitive for an attacker hammering /login. Keep it ≤12 and rate-limit the route.
• Debugging login failures: echo the stored hash's length and prefix. 95% of "wrong password" reports are truncated columns (VARCHAR(40), old MySQL) or a double-hashed value (hash applied twice during registration).

Extension points

• There aren't useful ones. If you need different behavior, override the service definition in your own bundle's config, or better: write a five-line class around password_hash()/password_verify() (PHP ≥5.5) and delete the dependency. That's a smaller diff than maintaining a Symfony2 bundle you can't upgrade.