Cilician Bundle Laravel Package

Product Decisions This Supports

Security posture as a roadmap line item, not an afterthought

• Turns "we should do something about breached credentials" into a shippable, defensible control. The free Pwned Passwords endpoint (k-anonymity, 5-character SHA-1 prefix) lets you block known-breached passwords at sign-up and reset without transmitting passwords or user identifiers. That is a days-not-quarters commitment with a clear acceptance test.
• Gives you an explicit answer for security questionnaires, SOC 2 / ISO evidence collection, and enterprise deal reviews. NIST SP 800-63B and OWASP ASVS both call for breached-credential screening, so this is a checkbox you can legitimately tick rather than argue about.

Scope arbitration: free password hygiene vs. paid account monitoring

• The package draws a clean line between two very different products. Password checking is free, privacy-preserving, and needs no legal review. Email/breach-account lookups send user email addresses to a third party, require a paid HIBP API key (~$4/month plus terms-of-use obligations), and trigger DPA, privacy-notice, and data-residency work.
• That split is the actual product decision: v1 security baseline (hashed password check only) versus v2 enterprise trust feature (domain-wide exposure monitoring, which the package does not model at all — that lives in HIBP's own dashboard). Sequence the free one first specifically to defer the privacy work.

Risk-prioritisation input, not just a signup validator

• "Password seen in N breaches" is a usable feature signal: it segments your user base by account-takeover risk and justifies MFA rollout, re-auth nudges, and forced resets for the highest-risk cohort. Frame it as telemetry that informs roadmap priority, not only as a gate.

Build vs. buy, honestly framed

• The real comparison is not "this package vs. nothing" but thin wrapper vs. ~150 lines of first-party client vs. vendored fork. The package's value is DI wiring, config defaults, and request-semantics encapsulation — real for a Symfony shop, close to zero elsewhere.
• The architecture fit is a gating decision, and it cuts against the brief: despite the "Laravel/PHP" framing, this ships as a Symfony bundle with a Bundle class and Symfony service definitions that Laravel's container does not consume. For a Laravel product, adopting it means importing Symfony components into an auth path for no functional gain. Buy the pattern (HIBP behind an internal BreachCheck interface), not the artifact.
• Treat the package as a reference implementation: mine it for endpoint paths, headers, and status-code semantics (404-means-not-breached, 401 bad key, 429 backoff, mandatory User-Agent), then rebuild natively in hours.

Documentation risk is itself a finding

• The supplied description talks generically about "shared building blocks, service providers, and small utilities" and never mentions Have I Been Pwned. When a package's own description does not describe what it does, assume onboarding cost is unbounded and that the code must be read line by line before you trust it near credentials.

When to Consider This Package

Consider it only if all of these hold:

• Your stack is genuinely Symfony, on a version the bundle supports, and you want the HIBP client injected and configured rather than hand-rolled.
• Your scope is narrow: password-breach check at signup/reset, plus occasional manual email lookups. You are not building a monitoring product on top of HIBP.
• You already hold (or will buy) an HIBP API key for any non-password endpoint and have accepted the rate limits, subscription cost, and terms of use (no bulk enumeration, no reselling).
• You have a maintenance answer. Zero stars, zero dependents, a single maintainer on Codeberg, no visible CI, no test suite, no stated licence, no Packagist evidence of tagged semver releases. The defensible path is to read the (small) source, pin the commit, confirm the licence, and vendored-fork it — or simply reimplement. In an authentication path, this is a reference implementation, not a dependency you take on trust.

Look elsewhere if any of these hold:

• You are on Laravel, Slim, or plain PHP. Framework mismatch; the bundle earns you nothing. Write a small first-party BreachCheck interface with an Http-backed adapter, bind it in a service provider, and move on.
• Security review will flag it. No dependents means no upstream CVE signal, no patch cadence, and a single point of trust sitting next to credential handling. Most organisations fail this at procurement — plan for vendoring from day one or don't start.
• You need enterprise HIBP capability — verified-domain monitoring, bulk or stealer-log data, webhooks. Use HIBP directly; a community bundle will not model it.
• You need predictability or scale. Any per-request call to a third party is a latency and availability dependency. At volume, self-host the Pwned Passwords range dataset or front it with a cache; never network-call in a hot login path.
• You are regulated, on-prem, or air-gapped. Any third-party egress of email addresses is a non-starter; the offline dataset is the only viable design.
• Licence cannot be confirmed. Undefined licensing blocks even snippet reuse — a hard stop before any code review effort is spent.

Non-negotiables if you proceed at all: cache range and catalogue responses, short timeouts, a circuit breaker, queue anything email-based, and fail open — an HIBP outage must never block signup, login, or password reset.

How to Pitch It (Stakeholders)

To executives: This is a small, cheap, high-visibility security control with a well-understood standard behind it. Screening passwords against known-breached lists is explicitly recommended by NIST SP 800-63B and OWASP ASVS, and the underlying password-check API is free and privacy-preserving — we send a five-character hash prefix, never the password and never a user identifier. It measurably reduces account-takeover and credential-stuffing exposure and gives us a defensible answer in security questionnaires and SOC 2 / ISO evidence collection. Effort is days, not a quarter; the only recurring cost appears if we extend beyond password checks. The one decision I need is scope: password hygiene now (free, no data-sharing implications, no legal review) versus email-breach monitoring later (recurring vendor subscription plus a privacy review, because that path sends user email addresses to a third party). My recommendation is to ship the free control first and treat the paid tier as a separate, later business case.

To engineering: The requirement is an HIBP client behind our own interface, with the password check as the must-have and email lookup as a follow-on. Do not wire this third-party package into the auth path. Despite the "Laravel/PHP bundle" label it is a Symfony bundle — a Bundle class and Symfony DI definitions that Laravel's container will not boot — and it carries zero stars, zero dependents, a single maintainer on Codeberg, no visible test suite, no CI, and no stated licence. The correct disposition is: read it as a reference implementation for endpoint paths, the hibp-api-key header, the mandatory User-Agent, and 404/401/429 semantics, then reimplement in roughly 150 lines using Laravel's Http, Cache, RateLimiter, and Queue primitives. Design constraints: configuration in config/services.php with the key from the environment and never logged; cache the near-static breach catalogue for hours; rate-limit to HIBP's ~1.5 req/sec; and fail open with a circuit breaker so an upstream outage never blocks signup or login. Keep the email-based check entirely out of the request path — queued job, emitting an EmailBreachDetected event for downstream notification or risk scoring. Add contract tests against recorded fixtures plus a fake implementation so CI never needs a key. Please come back with a cost estimate for vendored-fork versus build-from-scratch (I expect build to win), a licence confirmation on the source before any snippet reuse, and a note on whether self-hosting the Pwned Passwords range dataset is worth it at our volume.