Passwd Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow — and the honest answer is "none of the above." The package is a thin manager over primitives already in the platform: PHP's password_hash/password_verify and, within Laravel, the Hash facade. There is no capability gap to fund and no roadmap item that gets unblocked by adopting it. The decision it does surface is a policy one: what is our default posture toward security-adjacent dependencies that are pre-1.0, archived, and have zero dependents? This package is a clean worked example for answering that question once, in writing.
• Migrate legacy users vs. force a password reset. This is the only genuinely differentiated capability in the package: a hasher/checker split that lets you verify a plaintext against more than one historical hash format (the WordPress-style legacy case is the one worth keeping) and transparently rehash on successful login. That maps directly onto a real product decision — do we import credentials from an acquired app, forum, or legacy CMS, or do we absorb the conversion cost as a mass reset? Model both: reset rate, support-ticket load, churn on the affected cohort, and the engineering effort of the migration. Do this before dismissing the package on maintenance grounds alone.
• Scope the migration as a one-time backfill, not a permanent dependency. The strongest framing is that the checker/legacy path is a bounded migration tool with a deletion date. The product decision is the policy, not the library: verify-first-rehash-on-success, a legacy_hash flag set at import, and dead code removed when the flag clears. That decision outlives whichever library implements it.
• Platform baseline for the auth surface. The release drops Laravel 4.0 and moves to PSR-4 — it targets an already-obsolete framework era. Any product still there has a platform-retirement conversation to have, and that conversation is far more valuable than a library evaluation. Do not let a package spike become a distraction from getting off the end-of-life stack.
• A risk-register entry with a named owner, not a feature ticket. Password hashing sits on every signup, login, reset, and import. Archived upstream + pre-1.0 + zero dependents + security-adjacent scope is a combination that belongs in dependency risk review, with an explicit person accountable for the decision to adopt, wrap, or skip. If nobody will own that, the answer is skip.
• Release-notes discipline as a signal, not a deliverable. The changelog is housekeeping — PSR-4, tests, CI, style, "minor tweaks." Positive evidence of a careful maintainer and zero user-facing capability. It should generate no customer-facing commitment and no external release note.

When to Consider This Package

Consider it only when all of the following hold:

• The use case is a bounded legacy credential migration — imported hashes verified once, at account-claim or first-login time — on a Laravel 4.1-era application, and you have confirmed the native password_* functions and the Hash facade don't already cover the multi-format verify case.
• You can spike it in a throwaway branch, pinned to the exact 0.4.0-alpha tag with composer.lock committed. Never a caret range on a pre-1.0 security-adjacent package; alpha tags move.
• It sits behind your own adapter interface (one hash/check boundary, one container binding) so the blast radius of abandonment is a single class.
• Someone on the team has appetite to read the source — small surface, and the added unit tests make the audit meaningfully cheaper than it would otherwise be.
• Security review signs off on the default algorithm, the cost parameters, and the legacy-fallback behavior. Cost is a benchmark, not a guess: target ~100–250 ms per hash on production-class hardware, and do not lower it to make logins feel snappy.
• You've checked defined('PASSWORD_ARGON2I') before making Argon2 the default — it's a compile-time dependency, and it was frequently absent on stock builds of that era. Discovering this on the signup path is the worst possible failure mode.

Look elsewhere when:

• Passwords are on a revenue-critical or compliance-critical path. Use the Hash facade — vendor-maintained, already installed, and wrapped around the same primitives.
• You need a stable API contract, an upgrade guide, or a maintainer who will answer an issue. The upstream is retired under a GrahamDeprecated namespace; there will be no CVE patches and no PHP-version compatibility work. Adopting it means you own the fork whether or not you say so.
• The team cannot commit to owning it. Budget the maintenance or avoid it — the middle ground is where credentials get stranded.
• You're on modern Laravel. Every reason to reach for this disappears; the Hash facade plus a small custom checker for the one legacy format gets you the entire migration benefit with none of the dependency.
• The scope is "replace our primary hasher for new signups." That is a different, much worse decision than the migration use case, and it should be treated as such.

One config caveat worth putting in the decision record: if you need two hashers live at once (current writes vs. legacy verifies), do not fight the published config — the facade doesn't cleanly override per call. Bind your own instances and call the checker chain explicitly. That's roughly fifty lines, and noticing you had to write them is itself a data point about whether the dependency is pulling its weight.

How to Pitch It (Stakeholders)

For executives — one short paragraph. This is not a feature investment and it should not appear on a roadmap as one. The package is a small wrapper around password functions PHP already ships, published under a deprecated namespace with no dependents and no future security patches. The only business decision it informs is a real one: when we absorb users from a legacy system, do we migrate their existing passwords or force a reset? Migrating is usually cheaper in churn and support load, and this library handles that narrow case well enough to be worth a time-boxed spike. Everything else about it is a risk-register entry, not a build. If we adopt it, we adopt it behind our own interface, pinned to an exact version, with a written plan to remove it — and with a named owner for that plan.

For engineering — the working summary. Treat it as a migration utility with an expiry date, not an auth dependency. Pin 0.4.0-alpha, commit the lockfile, and wrap it in a one-class adapter so nothing in the application ever touches the Passwd facade directly. The whole exit plan is a paragraph: swap the adapter body to password_hash($plain, PASSWORD_BCRYPT, ['cost' => N]) and password_verify($plain, $hash). If you can't articulate that swap cleanly, you've coupled harder than the package deserves. Use the hasher/checker split for verify-any-then-rehash-on-success, gate the legacy checkers behind a legacy_hash flag set at import time so you're not running three formats on every login, and verify the plaintext before you hash and persist — and make sure the save doesn't re-trigger your setPasswordAttribute mutator into a hash-of-a-hash. Keep one real integration test that round-trips an actual hash; a stubbed binding proves your controller logic, not that credentials work. Add password to $hidden on every model that carries one, and never compare hashes with == or let them into logs and API payloads. Finally, and most importantly: if the real constraint is that we're still on a Laravel 4.1-era stack, say so out loud. That's the ticket, and this package is a footnote to it.