Symfony Password Exposed Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony-Centric: The bundle is designed specifically for Symfony applications, leveraging Symfony’s dependency injection, configuration system, and HTTP client stack. This makes it a natural fit for Symfony-based projects but introduces limited flexibility for non-Symfony PHP applications (e.g., Laravel, Lumen).
• Modular Design: The bundle abstracts the haveibeenpwned.com API interaction via the jord-jd/password_exposed library, providing a clean interface (PasswordExposedCheckerInterface). This aligns well with decoupled architecture principles.
• Security Layer: Acts as a pre-authentication security layer, validating passwords before hashing/storage (e.g., during registration/login). This is valuable for compliance (GDPR, PCI-DSS) and user protection.

Integration Feasibility

• Symfony Dependency: Requires Symfony (v5.4+ or v6.x) due to:
  • Symfony’s HttpClient, Cache, and Config components.
  • PSR-7/PSR-18 compliance for HTTP requests.
  • Blockers for Laravel:
    • No native Symfony integration (would need a wrapper layer or Symfony bridge).
    • Laravel’s HttpClient/Cache systems differ from Symfony’s (e.g., Guzzle vs. Symfony’s HttpClient).
• API Dependency: Relies on haveibeenpwned.com’s passwords API (free tier: 2,000 checks/day). Rate limits and API changes could impact reliability.
• Database Agnostic: No ORM/database dependencies, making it easy to integrate into existing auth flows (e.g., after password input, before hashing).

Technical Risk

Key Questions

1. Symfony vs. Laravel:
   • Is the project Symfony-based? If not, what’s the migration path for Laravel?
   • Would a custom wrapper (e.g., Laravel-specific service) be viable, or is a Symfony micro-service a better fit?
2. API Costs:
   • What’s the expected volume of checks? Will the free tier suffice, or is a paid plan needed?
   • How will rate limits be handled during traffic spikes?
3. Security Trade-offs:
   • Should checks be synchronous (blocking) or asynchronous (background job)?
   • How will false positives/negatives be managed (e.g., user notifications)?
4. Compliance:
   • Does the project require GDPR/PCI-DSS compliance? If so, how will breach notifications be handled?
5. Fallback Mechanism:
   • What’s the plan if the HIBP API is down? (e.g., local cache fallback, manual review)

Integration Approach

Stack Fit

Migration Path

Option 1: Symfony Integration (Recommended for Symfony Projects)

1. Composer Install:

   composer require jord-jd/symfony-password-exposed-bundle
   

2. Configure (config/packages/password_exposed.yaml):

   password_exposed:
       enable: true
       cache: cache.app
       cache_lifetime: 2592000  # 30 days
   

3. Service Integration:
   • Inject PasswordExposedCheckerInterface into controllers/services.
   • Example:

     use JordJD\PasswordExposed\Interfaces\PasswordExposedCheckerInterface;
     
     public function register(Request $request, PasswordExposedCheckerInterface $checker) {
         $password = $request->request->get('password');
         if ($checker->isExposed($password)) {
             throw new \RuntimeException("Password exposed in a breach!");
         }
         // Proceed with registration...
     }
     

4. Event Listener (Optional):
   • Hook into KernelEvents::REQUEST to auto-check passwords in forms.

Option 2: Laravel Integration (Custom Wrapper)

1. Install Underlying Library:

   composer require jord-jd/password_exposed
   

2. Create a Laravel Service:

   namespace App\Services;
   
   use JordJD\PasswordExposed\PasswordExposedChecker;
   use Psr\Cache\CacheItemPoolInterface;
   use Psr\Http\Client\ClientInterface;
   
   class LaravelPasswordExposedChecker
   {
       public function __construct(
           private ClientInterface $httpClient,
           private CacheItemPoolInterface $cache
       ) {}
   
       public function isExposed(string $password): bool {
           $checker = new PasswordExposedChecker($this->httpClient, $this->cache);
           return $checker->isExposed($password);
       }
   }
   

3. Bind Dependencies (AppServiceProvider):

   $this->app->bind(ClientInterface::class, function () {
       return new \GuzzleHttp\Client(); // PSR-18 adapter
   });
   

4. Use in Controllers:

   public function register(Request $request, LaravelPasswordExposedChecker $checker) {
       if ($checker->isExposed($request->password)) {
           return back()->withErrors(['password' => 'Exposed in a breach!']);
       }
   }
   

Compatibility

• Symfony: Seamless (designed for Symfony).
• Laravel: Possible but requires adapters for:
  • PSR-18 HTTP client (Guzzle → Symfony HttpClient or vice versa).
  • PSR-6 Cache (Laravel’s Cache → Symfony’s CacheInterface).
  • Config system (.env → YAML/XML).
• Other PHP Frameworks: Would need similar adapters or a standalone library (e.g., jord-jd/password_exposed directly).

Sequencing

1. Phase 1: Proof of Concept
   • Test in staging with a subset of users.
   • Monitor API rate limits and performance impact.
2. Phase 2: Integration
   • Symfony: Bundle installation + config.
   • Laravel: Custom service + dependency binding.
3. Phase 3: Rollout
   • Enable in non-critical flows first (e.g., registration).
   • Gradually expand to password resets/login.
4. Phase 4: Monitoring
   • Track false positives/negatives.
   • Set up alerts for API failures.

Operational Impact

Maintenance

• Symfony: Lower maintenance due to native integration.
• Laravel: Higher maintenance due to adapter layers.

Support