Sentinel Unique Passwords Laravel Package

Technical Evaluation

Architecture fit. This package is only architecturally relevant to applications that already run Cartalyst Sentinel as their authentication layer — it does not integrate with Laravel's default Auth guard, Breeze, Fortify, or Sanctum. Its mechanism is a decorator around Sentinel's hashing routine: when a password is being set or changed, the candidate plaintext is checked against the stored hashes of every other account, and the write is blocked if a match is found. That places the package directly in the synchronous write path of registration and password change — the two hottest, most latency-sensitive auth endpoints. Any assessment must therefore treat it as an auth-path dependency, not a utility library.

Integration feasibility. Technically small: a Composer requirement, a service-provider registration, and Sentinel's existing configuration. The real feasibility question is coupling. The package hooks into Sentinel's internal hashing contract; because Sentinel has its own release cadence and has been largely dormant, the compatibility surface is narrow and undocumented here. There is no evidence in the inputs of a maintained version matrix against Sentinel majors, PHP 8.1+, or Laravel 9/10/11.

Technical risk.

• Cost of the uniqueness check is O(n) over the user table. Because bcrypt/argon2 hashes are salted, identical passwords produce different hashes — uniqueness cannot be enforced by a database constraint or index. It can only be enforced by verifying the plaintext against every other stored hash at write time. At ~50–100 ms per Hash::check, 1,000 users implies roughly 50–100 seconds per registration or password change; 10,000 users makes the endpoint unusable. This is the headline risk and the primary go/no-go criterion.
• No atomicity / race window. Two users submitting the same password concurrently can both pass the check, since there is no transactional guarantee. The control degrades to best-effort under load.
• Coverage gaps. Whether the check applies to admin-created users, forced resets, API provisioning, soft-deleted accounts, and multi-tenant scopes is unstated. A partial control that looks complete is worse than a known gap for compliance framing.
• Credential-material exposure. Each write scans the full password column. For privacy/DPO review, that is a broad read of credential hashes for a single user action.
• Licensing. GitHub reports NOASSERTION; Cartalyst historically shipped some addons under commercial terms. This must be cleared by legal before any pilot.
• Maintenance signal. Zero stars, zero dependents, no releases since 2020-12-22. Effectively unmaintained.

Key questions.

• Do we actually run Sentinel, and on which major? If not, this package is out of scope entirely.
• Is "cross-user password uniqueness" a real compliance requirement, a customer ask, or an inferred nice-to-have? The common modern control is breached-password checking (e.g., HIBP k-anonymity), not cross-account uniqueness — confirm which requirement we are actually satisfying.
• What is the target maximum user count, and has the check been benchmarked at that size?
• Does the check cover all write paths (self-service, admin, reset, API), and how are soft-deleted and multi-tenant users scoped?
• What is the license, and who owns maintenance if we adopt?
• Is there a Hash::check cost ceiling or timeout we would need to impose, and what happens to registration when it is exceeded?

Integration Approach

Stack fit. Treat as N/A by default. It is a fit only for a Sentinel host. Do not introduce Sentinel in order to adopt this addon; that inverts the dependency and buys a dead ecosystem for a niche control.

Build vs. buy. Given the inputs, build is the stronger recommendation. The control logic is small and self-contained — intercept the password-set event, iterate other users' active hashes with Hash::check, reject on match. In-house implementation buys: scoping to tenant/active users, a hard cap and circuit breaker around the scan, async or rate-limited execution, metrics and audit logging, the ability to swap in breached-password checking, and immunity to the package's licensing and maintenance posture. The buy case is weak: zero dependents, zero stars, one release in four years, unresolved license.

Migration path (if adopting anyway).

1. Verify Sentinel major and PHP version compatibility first; confirm 5.1.0's PHP 8 support actually covers the runtime you target (PHP 8.1+ deprecation behavior is not established by a 2020 "PHP 8 support" note).
2. Legal clearance on the license before any code lands.
3. Load-test the password-write endpoint at realistic user volumes — 10x and 100x current — before enabling.
4. Roll out behind a feature flag; keep the flag off in production until latency is measured.
5. Instrument registration/password-change latency and rejection rates from day one.

Compatibility and sequencing. Sequence the work after the auth path is otherwise stable. Do not bundle with a Laravel or PHP upgrade, because a failure will be unattributable. Rollback is a Composer revert plus flag disable — cheap, which is the one favorable property here.

Operational Impact

Maintenance. You inherit an unmaintained package. There will be no security patches and no compatibility updates for future PHP or Laravel releases. Budget either a fork-and-vendor line item or a planned replacement with an in-house implementation. The 2020 last-release date is the load-bearing fact for this section.

Support. Zero stars and zero dependents means no community, no issue triage velocity, and no fallback maintainer. Escalation path is effectively "we fix it ourselves." For an auth-path component, that is a material operational exposure.

Scaling. The cost curve is the operational story: latency scales linearly with user count and is dominated by hash verification cost. Concretely, plan for a hard cap on table size scanned, a time budget on the check, and a documented fallback (allow the write and log) when the budget is exceeded. Without those, the registration endpoint becomes the app's most fragile surface and a trivial denial-of-service target.

Failure modes to watch.

• Registration timeouts as the user base grows past the low thousands.
• Race-condition bypass under concurrent registrations — control silently weakened.
• Coverage blindness: admin or API provisioning paths skip the check, so uniqueness is only partially enforced while being reported as enforced.
• Hash-migration breakage: rehashing to a new algorithm or cost invalidates the comparison assumptions.
• False compliance confidence: stakeholders believe duplicates are impossible; they are only made unlikely.
• License audit failure discovered post-deployment.
• Dead dependency: no upgrade path when the next PHP/Laravel major lands.

Ramp-up. Engineering learning cost is negligible — the package is small. The real ramp-up is organizational: building the discipline to ask "what does this actually enforce, on which paths, at what cost, under which license?" before approving an auth-path dependency. Recommend codifying the decision (build vs. buy, scope, cost ceiling, compliance mapping to breached-password vs. cross-user-uniqueness) in an ADR so the next team does not re-litigate or, worse, assume protection that was never wired up.