Pwned Validator Laravel Package

Product Decisions This Supports

• Password security baseline for account systems. The package wraps the Have I Been Pwned "Pwned Passwords" check as a Laravel validation rule, letting the team reject breached/compromised passwords at registration and password-reset without building or hosting a breach corpus. This directly supports decisions about whether to ship stronger credential hygiene in the current roadmap.
• Build vs. buy for security checks. Adopting a maintained, versioned package (now at a stable 1.0.0) is a "buy/borrow" decision that avoids owning HIBP API integration, k-anonymity request handling, timeouts, and error fallbacks ourselves. This frees engineering capacity for core product work.
• Roadmap item: secure authentication / compliance. Useful for SOC 2 / ISO-adjacent controls, enterprise security questionnaires, and any "we protect user accounts" marketing or contractual claim. It enables a concrete, demonstrable control rather than a policy statement.
• Use-case scoping. Best fit for consumer sign-up, B2B account provisioning, and any flow with user-set passwords. Less relevant where auth is delegated to an IdP (SSO/Social) and passwords are never stored.

When to Consider This Package

Adopt when:

• The product has first-party password authentication (Laravel-native auth, custom login) and the team wants breached-password rejection with minimal code.
• You want a validation-rule-level integration that fits existing FormRequest/validator patterns and is easy to unit-test and feature-flag.
• You value a semantic-versioned dependency — 1.0.0 signals API stability for a production adoption decision — and can tolerate third-party API dependency risk (HIBP availability, rate limits).
• The team is comfortable with the k-anonymity model (only a hash prefix leaves the app), which is the privacy-respecting way to do this.

Look elsewhere when:

• Auth is fully outsourced to an IdP that already enforces breached-password policy (avoid redundant checks).
• You need offline/air-gapped validation (this relies on an external HTTP API; a locally hosted Pwned Passwords dataset or a package supporting a self-hosted endpoint is a better fit).
• You require a zero-external-dependency security control or have strict data-residency constraints on outbound calls.
• The release notes for 1.0.0 are thin (changelog link only) — if you need documented security guarantees, audit the code and confirm error/timeout behavior before committing.

How to Pitch It (Stakeholders)

To executives: This is a low-effort, high-signal security upgrade. Adding breached-password rejection is a recognizable, checkable control that strengthens account security and supports security/compliance conversations — at essentially the cost of one Composer dependency and a validation rule. It reduces account-takeover risk from credential-stuffing attacks without new infrastructure.

To engineering: A Laravel-native validation rule for the HIBP Pwned Passwords API, now at a stable 1.0.0. It slots into existing FormRequest/validator flows, uses k-anonymity (only a SHA-1 prefix is sent), and keeps integration logic out of our codebase. Recommend a short spike to confirm timeout/failure behavior and to decide fail-open vs. fail-closed on HIBP outages, plus a feature flag for rollout.