- Does this Symfony password exposed bundle work with Laravel?
- Not directly. It is a Symfony bundle built around Symfony Flex, the Symfony service container and Symfony configuration, so it cannot be installed and booted as-is in a Laravel application. The practical option is to depend on the underlying framework-agnostic core library it wraps, or to reimplement the small range-lookup algorithm behind a Laravel service provider, config file and validation Rule. Most Laravel teams find the reimplementation path cheaper than pulling Symfony components in for a single feature.
- How does the package check whether a password has been exposed in a data breach?
- It uses the Have I Been Pwned Pwned Passwords range API with k-anonymity. The plaintext password is SHA-1 hashed, the first five hex characters are sent to the range endpoint, and the response body is scanned for the remaining 35 characters of the hash. Only that five-character prefix leaves your server, so neither the plaintext nor the full hash is ever transmitted. This makes it a privacy-friendly design that is reasonable to document in a DPIA or security design review.
- How do I install the package with Composer?
- Installation is a standard Composer require from your project root, but confirm the exact vendor/package name on Packagist first because the Composer name and the name shown in the README differ in some listings. Because it is a Symfony bundle, installation also expects Symfony Flex, symfony/config and symfony/http-client to be present. In a Laravel-only codebase you would instead install the framework-agnostic password_exposed core library and wire it yourself.
- What configuration options does the bundle expose?
- Configuration lives under the password_exposed YAML key and all keys are optional. Available options are enable (useful for disabling the check in development), http_client for a custom PSR-18 client service ID, cache for a PSR-6 cache service ID defaulting to cache.app, cache_lifetime in seconds defaulting to 2592000 (30 days), and request_factory plus uri_factory for custom PSR-17 factories. In a Laravel port these map naturally onto a config file, the Cache facade and the HTTP client.
- Which PHP and Symfony versions are supported?
- The README states support for PHP 7.4 through current releases and Symfony 4.4 through 8. There is no published supported-version matrix or deprecation policy beyond that statement, so pin versions and verify against your own PHP runtime. If you are targeting Laravel, PHP version support is the only part of that matrix that is relevant to you.
- How do I add an exposed-password check to Laravel registration or password reset?
- You need the check to run before the password is hashed and persisted, not as an after-the-fact audit. In Laravel terms that means a custom validation Rule, an after-hook or a form request rule that calls the checker and fails validation with a clear message pointing the user to a stronger password. Wrap the call in a cache so repeated submissions do not hit the API, and add a timeout plus fail-open or fail-closed policy so a HIBP outage does not block registration entirely.
- Should I use the bundle or reimplement the check myself?
- For a Laravel codebase, reimplementation is usually the better trade. The algorithm is bounded and well specified: SHA-1 the plaintext, take the first five hex characters, GET the range endpoint, scan the response for the remaining 35 characters, and cache the prefix response. That is roughly 60 to 120 lines plus tests, which is often less total effort than adapting a thin Symfony wrapper. Rebuilding also removes third-party version, license and maintainer risk entirely.
- Is it safe to send password data to an external API?
- With this k-anonymity approach, only a five-character SHA-1 prefix is sent, and the API returns a list of matching hash suffixes rather than confirming any specific password. No plaintext and no full hash leave your infrastructure, which is normally acceptable for security and privacy review. Note that a hash prefix still constitutes a network call on the authentication path, so document the third-party dependency in your design and privacy documentation.
- What are the production risks of relying on the Have I Been Pwned API?
- The range endpoint adds latency and a hard external availability dependency directly on your registration and password change flows. The default 30-day cache lifetime also means a newly breached password can pass the gate until the cached prefix expires, producing false negatives. Use a shorter cache lifetime if freshness matters, set a short HTTP timeout, and decide deliberately whether to fail open or fail closed when the API is unreachable. Verify current HIBP terms and rate limits before committing rather than relying on older figures.
- Is the package actively maintained and what license does it use?
- It is licensed LGPL-3.0, which is generally workable for hosted SaaS but not a permissive default, so get legal sign-off if you plan to modify and distribute it. Community signal is weak: a single maintainer, minimal stars and no dependents, with a release history that looks largely automated. That combination makes abandonment plausible, which is a strong argument for depending on the core library or rebuilding the logic in-house.