Sentinel Unique Passwords Laravel Package

Product Decisions This Supports

Feature-level: a security/abuse control, not a growth feature. This addon enforces password uniqueness across the whole user base, so it supports one narrow requirement: preventing two accounts from sharing a credential. In product terms that maps to abuse and integrity use cases — shared-account detection, multi-accounting around trials/promotions, seat or license sharing, and fraud-ring defense. It does not support authentication strength, MFA, or breach-corpus checking (e.g., Have I Been Pwned), which are the controls customers and auditors actually ask about. Be explicit about that distinction before anyone puts "password security" on a roadmap slide.

Roadmap-level: it is an upgrade gate, not a destination. The only substantive release signal is "Add PHP 8 support" shipped as a minor (5.1.0) in December 2020 — after PHP 8.0 had already gone GA. For a PM the relevant read is that this package sits on the critical path of any Laravel/PHP modernization while you remain on Cartalyst Sentinel, and that its cadence is slow enough to bound your cadence. Treat it as a line item in the platform-modernization epic with an explicit "remove or replace" exit, not as a component to design around.

Build vs. buy: this is a build, and the decision is easy. Stripe the framing down and the requirement is "reject a password that matches an existing one." That is a validation rule plus a lookup — small, testable, fully owned. Against that, buying means taking a 0-star, 0-dependent, single-purpose addon on a stale release line, with a NOASSERTION license that legal will have to adjudicate before you can ship it. The buy case rests entirely on "we are already deep in Sentinel and want zero code," which is a weak reason to add an unauditable dependency to the auth path. Recommendation: build in-house if the requirement survives product review at all.

Two product questions to settle before engineering effort. First, is cross-user password uniqueness actually a requirement we can defend? It creates a deliberate enumeration signal at registration (a submitted password can be tested against the user base), and it interacts badly with incident response — a single credential compromise becomes a multi-account compromise by construction. Second, what is the mechanism? Comparing bcrypt hashes directly cannot work because per-user salts differ, so the addon must store or compute some deterministic comparison key over passwords. If that key is a fast, unsalted digest sitting in the user table, a database breach escalates from "crack passwords one at a time" to "crack the whole corpus at GPU speed." That detail decides whether this passes security review. Get it answered in writing before any pilot.

When to Consider This Package

Consider it only if all of these hold:

• You are already running Cartalyst Sentinel in production and are not planning to migrate off it. The addon is meaningless outside Sentinel's hashing pipeline.
• The uniqueness requirement is already signed off by security and legal, with the enumeration and breach-amplification tradeoffs explicitly accepted.
• You are on, or capping at, a Laravel/PHP combination the package actually installs against — and you have verified the framework constraint moved, not just the PHP constraint. A widened php requirement with a stale illuminate/* cap buys you nothing.
• You can accept the maintenance burden: no meaningful release since 2020, so assume you may fork it. Confirm the license permits that before you build a dependency on it.
• The requirement is genuinely a checkbox and the alternative (a few days of in-house work) is more expensive than the integration and legal review.

Look elsewhere — or build — if any of these hold:

• You are not on Sentinel. Laravel's first-party auth stack (Fortify/Breeze/Jetstream, or Sanctum plus a policy) is the default; Sentinel is a legacy path with its own support questions, and this addon inherits all of them.
• You need a maintained dependency with a real CI matrix, a changelog, and an issue triage cadence. Zero stars and zero dependents means no ecosystem signal of any kind — you are the only one who will find the bugs.
• You need more than pairwise uniqueness: breached-password screening, entropy/strength policy, rotation, MFA, or SSO. None of that is here.
• Your target stack is beyond what was validated in 2020. "Supports PHP 8" from that era does not imply it is exercised on later runtimes, and deprecation notices in the auth path show up as exceptions in strict apps.
• Legal cannot clear NOASSERTION quickly. An unclear license on an authentication component is a stop-work condition, not a to-do.

How to Pitch It (Stakeholders)

To executives: there is a small open-source addon that prevents two users from having the same password. It addresses a narrow abuse concern — shared or duplicate accounts around trials, promotions, and seats — and it does nothing for the security questions customers actually ask about (breach checking, MFA, SSO). It is a zero-adoption, single-maintainer package last released in 2020, sitting on top of an older authentication library, with an unclear license. My recommendation is not to adopt it: the requirement, if we keep it, is a few days of our own engineering, which removes the dependency, the license question, and the upgrade risk entirely. If we do keep it, we should treat it as a stopgap with a named owner and a removal date.

To engineering: assume this is unmaintained. Verify three things before any spike: whether the framework constraint widened alongside the PHP constraint, how duplicate detection is actually computed and whether that representation is safe at rest, and what the per-registration cost is when the user table is large. Plan the work as two isolated deploys — version bump first, runtime bump second — so any failure is attributable, and do not bundle it with a framework upgrade. Give me a build estimate for an in-house equivalent; that number is the benchmark this package has to beat.

To security and legal: two items need a decision, not an opinion. First, the license is unclassified (NOASSERTION) — can we ship or fork it? Second, cross-user uniqueness means a submitted password can be tested against our user base, and one shared password becomes a multi-account incident. Confirm we accept both, or we drop the requirement.