Symfony Password Exposed Bundle Laravel Package

Product Decisions This Supports

• Password policy / credential hygiene roadmap item: block or warn on breached passwords at registration, password reset, and email/username change. This is the core product decision; everything else is delivery detail.
• Compliance narrative: NIST SP 800-63B explicitly requires screening new passwords against a list of commonly-used and breached passwords. This maps loosely to GDPR Art. 32, PCI-DSS 8.x and SOC2 CC6.x evidence packs. A PM can cite a concrete, testable control rather than "we do security."
• Build vs. buy — the decision is narrower than it looks: the underlying mechanism is a Have I Been Pwned Pwned Passwords range query (SHA-1 the password, send the first 5 hex characters, compare returned suffixes). That is roughly 30 lines of code and the API is free and unauthenticated. So the real decision is "adopt a wrapper vs. write it in-house," not "buy breach detection." Frame it that way or the cost case collapses.
• Fail-open vs. fail-closed policy: a genuine product decision, not an engineering one. If HIBP is slow or down, do we block signup (security-first, conversion-hostile) or allow and log? The PM owns that call and the timeout budget around it.
• UX surface decisions: hard block vs. advisory nudge, whether to surface match counts ("this password has appeared in breaches 12,345 times"), and where in the funnel the check sits (before submit vs. inline validation).
• Risk auditing: logging exposure checks without the password or full hash for anomaly detection and compliance evidence.

When to Consider This Package

Important framing: this is a Symfony bundle, not a Laravel package. It registers DI services, reads config under a password_exposed: key, and ships a Symfony Validator constraint. There is no Laravel service provider, no publishable config, no facade, no validation rule. For a Laravel codebase the honest position is: treat this as a reference implementation, not a dependency.

Adopt it directly only if:

• Your stack is genuinely Symfony 5.4+/6.x+ and you already run Symfony's HttpClient and Cache components — then the PasswordExposedCheckerInterface and PasswordExposed constraint save you real glue code.
• You want cached 30-day TTL behavior configured out of the box.

Look elsewhere — or write it yourself — if:

• You're on Laravel, Lumen, or framework-agnostic PHP. You'd be booting Symfony's HttpClient/Cache/Config inside Laravel to avoid writing ~30 lines. Depend on the underlying jord-jd/password_exposed library and bind it in a service provider, or implement the range query directly against Http:: and Cache::.
• Vendor confidence matters — and in an auth path it should. This has 1 GitHub star, 0 dependents, a single maintainer, and a rename history (divineomega → jord-jd) with a v1.0.0 "automated migration release." That's a supply-chain signal, not a feature.
• LGPL-3.0 creates legal friction. It's weaker copyleft than GPL, but legal review still costs calendar time you can avoid entirely by writing the client yourself.
• You need bulk/batch checking at user-import time. Per-request latency and fair-use expectations make live lookups unsuitable; HIBP publishes downloadable hash-range files for offline screening instead.
• You need feeds beyond HIBP (internal breach corpora, commercial threat intel).

How to Pitch It (Stakeholders)

Executives — pitch the capability, not the package. "We can screen every new and changed password against hundreds of millions of breached credentials, for free, without any identifiable data leaving our infrastructure — we send five characters of a hash and receive a match count back. This is a control NIST 800-63B explicitly asks for, and it's the single highest-leverage defense against credential stuffing." Then give the honest engineering footnote: the vendor wrapper is a 1-star Symfony-only bundle with no dependents, so engineering will implement the equivalent themselves against our own HTTP client and cache. Same compliance story, no third-party dependency sitting in the authentication path.

Engineering — the mechanism is small and well-understood. SHA-1 the candidate password, request api.pwnedpasswords.com/range/{first5}, compare the returned suffixes. Cache the prefix range responses for 24h–30d and nearly all traffic disappears. Decide these before writing code: fail-open (recommended for signup conversion, with a metric so you can see it firing), a hard block on match with a friendly "choose a different password" message, a 1–2s timeout so a slow API can never stall registration, and a strict rule that neither the password nor the full hash is ever logged. On Symfony, the bundle is a legitimate shortcut. On Laravel, budget a day for a service provider, validation rule, config, and tests — and take the underlying library, not the bundle.

Security — position it as one layer, not the answer. k-anonymity means HIBP cannot recover the password from the query, so this is a low-privacy-risk control. But it stops reuse of known-breached credentials, not phishing or credential theft. Pair it with length-first policy (NIST favors length plus breach screening over composition rules) and keep MFA on the roadmap so the breach check isn't mistaken for account-takeover protection.