Password Hasher Laravel Package

Product Decisions This Supports

• Build vs. buy for password hashing. The real decision this package informs is not "should we add a dependency" but "do we build a hashing policy layer or keep using framework defaults?" Symfony's component is the buy option: MIT-licensed, core-team reviewed, and a subtree split of symfony/symfony, so the code is exercised at massive scale. Building an equivalent in-house is a poor use of engineering time.
• Whether multi-algorithm hashing is a real product requirement. The PasswordHasherFactory named-hasher model supports a genuine roadmap item: per-tenant or per-role algorithm tiers (enterprise tenants on Argon2id, standard accounts on bcrypt). If no such requirement exists, this decision resolves to "tune Laravel's Hash cost factor" and the evaluation closes — that's a valid, cheap outcome.
• Hash rotation as a lifecycle capability, not a one-off migration. needsRehash() is the actual product value here. It turns "rehash on successful login" from a bespoke subsystem into a one-line check plus a listener. That makes algorithm upgrades a repeatable policy operation rather than a project.
• Retiring a legacy credential estate. If we have MD5/SHA-1 rows, or an acquisition's inherited auth table, LegacyPasswordHasher and MigratingPasswordHasher give a verifiable bridge with a defined removal date instead of a permanent compatibility scar.
• Polyglot platform consistency. If some services are PHP/Laravel and others are Symfony, one hashing policy abstraction reduces audit and compliance surface — one story for "how we hash" across the estate.
• Roadmap sequencing. Adoption is gated on PHP version floor (v8.x requires PHP 8.4+, older fleets pin 6.4/7.x) and on a defined legacy-verifier sunset window. Both are planning inputs, not engineering details.

When to Consider This Package

Consider it when at least one of these is true:

• You need more than one hashing algorithm live at the same time, selected by policy (tenant tier, account type, jurisdiction).
• You have existing non-bcrypt hashes that must keep authenticating while they migrate, and you want a supported legacy-verifier path.
• You want a first-class, testable rehash-on-login mechanism with a clean hash / verify / needsRehash contract.
• You're on Symfony already — in which case you get this via security-bundle and should not install it directly.

Look elsewhere or defer when:

• You're a standard single-algorithm Laravel app. Illuminate\Hashing wraps password_hash()/password_verify() and already satisfies NIST 800-63B and OWASP guidance with a sane cost factor. Adopting this is dependency surface with no behavioural gain.
• You expect a drop-in Laravel driver. It isn't one. This is additive: you'd write an Illuminate\Contracts\Hashing\Hasher adapter, a service-provider binding, and a login listener. Budget 0.5 day for a proof of concept, 1–2 weeks for production rollout across web, API, password reset, and admin — plus tests proving old hashes still authenticate.
• Your fleet spans PHP 8.1 through 8.4+ and you can't absorb multiple pinned minors and an upgrade treadmill.
• You need audit logging of algorithm changes for SOC2/ISO. The package doesn't provide it; you'd emit that from the rehash hook yourself.
• You read "Dependents: 0" as abandonment, or "807 stars" as independent popularity. Both are subtree-split packaging artifacts. Neither is a signal. Don't let an SCA tool drive this decision, and don't let a star count substitute for it.

How to Pitch It (Stakeholders)

To executives: This is a small, free, security-reviewed component from Symfony that lets us support more than one password-hashing standard at once and upgrade old password hashes automatically as users log in. It's the buy option in a build-vs-buy call we'd otherwise make badly. It doesn't touch our database schema, it doesn't require a bulk data migration (password hashes can't be recomputed without plaintext — the industry-standard approach is upgrade-on-login), and it's MIT-licensed with no meaningful supply-chain exposure.

To engineering: It's not a Laravel package and it doesn't replace Hash. It's a Symfony component we'd wrap in an adapter behind Illuminate\Contracts\Hashing\Hasher. The value is the PasswordHasherFactory named-hasher model and needsRehash(). The real work isn't the adapter — it's the rehash-on-login listener, the legacy verifier, and the tests. It's security-critical code: bugs mean account takeover or lockout, so this gets a proper review and staged rollout, not a Friday ship.

What I need to decide to proceed: (1) Do we actually need multi-algorithm hashing, or is the requirement "bcrypt with a sane cost"? (2) What's the PHP floor across adopting services — that picks the branch. (3) Who owns the rehash login hook and what's the rollback if the rehash write fails mid-login? (4) What's our p95 login latency SLO, and what cost factor fits inside it at peak? (5) How many legacy formats must stay verifiable, and until when — that defines the bridge's removal ticket.

The honest recommendation: if the answers to (1) are "no, not really," we tune Hash and close this. If they're "yes, we have legacy rows and a tiered policy," this is the right tool and the effort is small and well-understood.