Laravel Needs Auto Rehash Laravel Package

Product Decisions This Supports

• Build vs. buy (the headline decision). The package is glue code: an event listener that, after a successful authentication, calls Hash::needsRehash($user->password) and, if true, writes back Hash::make($plaintext). That is roughly 10–15 lines plus tests. The package is archived, last released 2023-02-20, 66 stars, single maintainer. For a security-relevant path, this supports the decision to build in-house and use the package only as a reference implementation.
• Roadmap: hashing-strength upgrades become routine, not a project. Bumping bcrypt rounds (e.g., 10 → 12) or migrating drivers (bcrypt → argon2id) normally implies a forced password-reset campaign or a long-running "rehash on login" project. With this pattern, raising the cost factor becomes a one-line config change; the user population self-migrates over the following weeks of normal logins. That turns a multi-sprint migration item into a config ticket.
• Security/compliance baseline work. OWASP and NIST guidance both say to upgrade stored hashes when cost parameters change. This is a cheap, high-signal line item for an audit response, SOC2 evidence, or a "we remediate stale crypto" hygiene initiative — no user-visible change, no support load.
• Inherited/legacy application triage. When taking over a Laravel app of unknown vintage, this is the fastest way to quietly strengthen weak hashes (old cost factors, legacy algorithm) without coordinating with end users or B2B customers who cannot be forced through a reset flow.
• Reduces blast radius of future security incidents. Post-incident hardening ("raise the cost factor and rotate to argon2id") becomes a low-risk, reversible config change rather than a feature release with comms, support macros, and CX review.
• Informs dependency policy. Low score (0.225) and archived status are a useful forcing function to formalize "no unmaintained packages on the auth path" — if adopted at all, it should be vendored/forked with an owner and a test suite, not pulled from Packagist at deploy time.
• Non-goals it clarifies. It does not handle password policy, breach-list checks, MFA, session invalidation, or rehash-on-reset (Laravel already rehashes whenever you call Hash::make on a new password). Framing it as a single-purpose migration accelerator keeps scope honest.

When to Consider This Package

Consider the pattern (and read this package's source) when:

• Production hashes were generated under weaker parameters than your current config, and you want them upgraded automatically as users log in.
• You use Laravel's standard session guard and the built-in auth event system — the listener is additive, so login controllers, form requests, and views stay untouched.
• You cannot force a global password reset — large consumer bases, B2B tenants, kiosk/offline clients, or contractual constraints.
• You want a one-time, low-effort migration before swapping the Hash driver or raising bcrypt rounds in config/hashing.php.
• You are comfortable validating the listener's ordering guarantee yourself: it must fire after credentials are verified. Rehashing on an unauthenticated attempt would let an attacker overwrite a user's password hash with a hash of a wrong password — the single most important correctness check here.
• Your app uses multiple guards/hashers or per-tenant hashing config and you need one consistent upgrade path.

Look elsewhere — or just write it yourself — when:

• Greenfield or small codebase. Write an EventListener bound to the login event, plus a feature test. You inherit no maintenance risk and control the semantics (logging, queueing, notifications).
• Archived-dependency risk is unacceptable. The package has not shipped since Feb 2023; assume no Laravel 11/12 compatibility work, no security patches, and no response to issues. If your policy requires maintained dependencies, vendor the code or reimplement.
• Password-less / federated auth. SSO, OIDC, magic links, API tokens, or "remember me"-only flows never surface a plaintext password at login — there is nothing to rehash. Same for apps that hash client-side.
• You only care about password-set time. Laravel already hashes with the current config on registration, reset, and change. This pattern only matters for the backlog of existing hashes.
• Compliance demands vendor support or a maintained SLA. Fork it, own it, document it.
• You need observability the package doesn't give you — counts of rehashed users per day, alerts when migration stalls, or exclusion lists for service accounts.

How to Pitch It (Stakeholders)

To executives (one paragraph): Password hashing strength decays as hardware gets faster, and industry guidance says we should upgrade stored hashes when our cost settings change. Normally that means forcing every user through a password reset — a support and churn event. There's a well-known pattern that upgrades each user's hash silently at their next successful login, so we get stronger security with zero user friction and no reset campaign. The specific open-source package that implements it is tiny and no longer maintained, so the recommendation is to adopt the pattern, not the dependency: a small, tested listener of our own, roughly a day of engineering including tests. Net effect: better security posture, lower migration risk, no user-facing change.

To engineering: Add a listener on the successful-login event that calls Hash::needsRehash($user->password) and, when true, persists Hash::make() of the just-validated plaintext. Requirements: fire only after authentication succeeds; suppress password-changed notifications and remember-token invalidation; avoid re-hashing on every request; log a counter/metric rather than the value; make the write idempotent and consider queuing it if a cost-factor bump would otherwise spike database writes across the user base. Sequence the rollout as ship listener → observe → raise bcrypt cost or switch driver → monitor the rehash metric until it flattens. Do not take a dependency on an archived 2023 package for this; copy the ~10 lines, credit the source, and add the tests it never had.