Product Decisions This Supports
- Whether to add breached-password screening at signup, reset, and login. Cilician wraps the Have I Been Pwned (HIBP) APIs — most importantly the Pwned Passwords range lookup, which uses k-anonymity (only a 5-character SHA-1 prefix leaves our infrastructure, never the plaintext or full hash). This is a blocking-vs-warning product decision tied to NIST 800-63B and OWASP ASVS guidance, and increasingly a checkbox in enterprise security reviews.
- Build vs. buy for a security surface. The real decision isn't "write an HIBP client from scratch" — it's "do we ship breach awareness at all, and do we spend engineering days or composer minutes on it?" An existing client collapses the estimate, but only if it's trustworthy and maintained; here, zero stars and zero dependents mean the answer is closer to "fork it" than "depend on it."
- Roadmap sequencing of trust-and-safety work. If breached-password checking is competing against MFA enrollment, a client that takes an afternoon to trial lowers the cost of validating which ships first.
- Account-exposure and breach-notification features. The authenticated breach endpoints (paid HIBP key) support flows like "your email appeared in a breach, rotate credentials," tenant-level exposure dashboards for B2B accounts, and incident-response triage after a third-party disclosure.
- Risk-scoring inputs for fraud and abuse. Exposure signals can feed account-takeover risk models or security-posture reporting as a premium feature.
- A caution flag on discovery and due diligence. The package's own description ("domain-specific integrations") does not say "HIBP client." That gap between marketing copy and actual capability is itself a product process finding: description quality is a leading indicator of maintenance quality, and buyers of security features should not be the ones discovering the mismatch.
When to Consider This Package
Consider it when:
- You're on PHP 8.1+ / Laravel and want a fast spike to validate UX — warning vs. hard block, retry copy, where in the flow the check sits — before committing to first-party code.
- You want the keyless Pwned Passwords range check and don't yet want to spend a sprint on it.
- You're comfortable treating the repository as a starting point you will vendor or fork, not a dependency you
composer require into production.
Look elsewhere, or reject it, when:
- Maturity signals matter. Zero stars, zero dependents, no observable production usage, hosted on Codeberg rather than the ecosystem's discovery surface. No community regression coverage, no patch flow; any PHP 9 incompatibility or HIBP API change becomes your bug.
- Security-adjacent trust surface is in scope. A package that handles user emails and an API key, with no disclosure process or CVE history, is a poor supply-chain bet. The code paths that would log request URLs, emails, or the API key are unverified.
- You need contractual support or an SLA. Go direct to HIBP's commercial API and own the client; note that the breach endpoints require that paid key regardless, so the package doesn't remove that line item.
- You only need the password range check. That's a small, stable endpoint — a hashed prefix request and a string split. Roughly 1–2 days of first-party code with
Http::fake() contract tests is often lower total risk, and it keeps the surface area small.
- You're not on PHP/Laravel, or you need queued/bulk throughput where a batch design matters more than a convenience wrapper.
Regardless of path, verify: API key injection (never logged), 429 + Retry-After handling, jittered backoff, the Add-Padding option on password ranges, response caching TTL for breach metadata (24h is a reasonable default), and whether the client fails open or closed when HIBP is unavailable. Pin the version, mirror it behind your own namespace, and pin integration tests against HIBP's documented test data.
How to Pitch It (Stakeholders)
To executives: Credential stuffing is the most common account-takeover vector, and a large share of users reuse passwords already exposed in public breaches. This package is a thin PHP client over Have I Been Pwned — the industry-standard exposure dataset — which lets us trial password screening and account-exposure alerts in days rather than a sprint. It's a low-cost, high-visibility trust feature: fewer takeovers, fewer support tickets, and a concrete answer to the security questions that show up in enterprise and vendor-security reviews. The caveat is that the package itself is a small, unmaintained open-source project with no adoption, so the honest framing is "this is a reference implementation we'll own," not "this is a vendor dependency." That reframes the ask as an engineering-hours line item — roughly a day or two to wrap or vendor — rather than a commercial risk.
To engineering: It's an HTTP/JSON client over HIBP's v3 API plus the Pwned Passwords k-anonymity range endpoint. The range endpoint is the valuable part, and because it sends only a 5-character hash prefix, no plaintext or full hash ever leaves our infrastructure — which keeps the privacy review simple. The breach-lookup endpoints need a paid HIBP key, so factor that into the estimate. Given zero stars, zero dependents, and unverified handling of retries, timeouts, Retry-After, and logging, my recommendation is not to composer require it: either spend 1–2 days building a thin internal client behind a BreachLookup interface using Illuminate\Support\Facades\Http (with Http::fake() tests covering 200/404/429/503/timeout), or fork and pin it into our namespace if the API shape proves genuinely convenient during a half-day spike. Either way, run the check as a queued job behind a feature flag, fail open for password checks, cache results with a TTL, and guarantee emails never land in logs or traces.