Bricks Scrypt Password Encoder Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony2/3 Focus: The bundle is explicitly designed for Symfony2/3, which may introduce compatibility risks if integrating with modern Laravel (v9+) or non-Symfony PHP stacks. Laravel’s authentication system (e.g., Illuminate\Hashing) uses a different abstraction layer, requiring a wrapper or adapter layer.
• Scrypt as a Security Upgrade: Scrypt offers superior protection against brute-force attacks compared to Laravel’s default bcrypt (via hash::make()). If security hardening is a priority (e.g., high-value user data, regulatory compliance), this is a compelling fit.
• Bundle vs. Standalone: The package is a Symfony bundle, not a standalone PHP library. Laravel lacks native bundle support, necessitating extraction of the core ScryptPasswordEncoder logic or a custom facade.

Integration Feasibility

• Core Dependency: The bundle relies on the scrypt-php library, which must be compatible with Laravel’s PHP version (8.0+). Test for:
  • PHP 8.x compatibility (e.g., named arguments, type hints).
  • Memory/performance overhead of scrypt vs. bcrypt (scrypt is CPU/memory-intensive).
• Symfony-Specific Components:
  • SecurityBundle integration (e.g., encoder_factory, user_provider).
  • ParameterBag for configuration (Laravel uses config() or environment variables).
• Laravel Auth System:
  • Replace Hash facade or extend Illuminate\Contracts\Hashing\Hasher with a custom scrypt implementation.
  • Update users table migration to store scrypt hashes (longer format than bcrypt).

Technical Risk

• Breaking Changes:
  • Migrating existing bcrypt hashes to scrypt requires a one-way rehashing process (risk of user lockouts if not handled gracefully).
  • Symfony’s UserInterface assumes a specific encoder contract; Laravel’s Illuminate\Auth\Authenticatable may need adjustments.
• Performance:
  • Scrypt’s computational cost could slow down login flows if not tuned (adjust N, r, p parameters).
  • Benchmark against bcrypt in staging before production rollout.
• Library Maturity:
  • Low stars/downloads suggest unproven adoption. Validate scrypt-php stability in Laravel’s environment.
  • No active maintenance (last commit: 2016). Fork or patch if critical bugs emerge.

Key Questions

1. Security Requirements:
   • Is scrypt’s overhead justified for our threat model? (Compare to bcrypt/PBKDF2.)
   • Are we compliant with standards (e.g., NIST SP 800-63B) requiring scrypt?
2. Migration Strategy:
   • Can we rehash bcrypt hashes in batches without disrupting users?
   • How will we handle legacy logins during migration?
3. Performance:
   • What are the N, r, p parameters for scrypt? (Default: N=16384, r=8, p=1?)
   • Will scrypt’s memory usage impact shared hosting (e.g., Heroku, shared VPS)?
4. Testing:
   • Are there Laravel-specific tests for the extracted scrypt logic?
   • How will we test edge cases (e.g., malformed hashes, slow attacks)?

Integration Approach

Stack Fit

• Laravel Compatibility:
  • Option 1: Extract Core Logic
    • Isolate the ScryptPasswordEncoder class from the Symfony bundle and wrap it in a Laravel-compatible trait/interface (e.g., Illuminate\Contracts\Hashing\Hasher).
    • Example:

      class ScryptHasher implements Hasher {
          public function make($value, array $options) {
              return (new ScryptPasswordEncoder($options))->encodePassword($value, null);
          }
          // ... other Hasher methods
      }
      

  • Option 2: Symfony Bridge
    • Use Laravel’s SymfonyBridge (e.g., spatie/laravel-symfony-support) to integrate the bundle as a service provider.
    • Higher complexity; may introduce unnecessary Symfony dependencies.
• Dependencies:
  • Requires tarcieri/scrypt-php (PHP extension or pure-PHP polyfill).
  • Ensure ext-sodium is unavailable (scrypt-php falls back to pure-PHP).

Migration Path

1. Phase 1: Proof of Concept
   • Extract ScryptPasswordEncoder and test in a Laravel app:
     • Verify hash generation/verification.
     • Benchmark against Hash::make().
   • Update config/auth.php to use the new hasher:

     'hashers' => [
         'scrypt' => App\Hashing\ScryptHasher::class,
     ],
     

2. Phase 2: Dual-Write Migration
   • Add a hash_algorithm column to users table (e.g., bcrypt/scrypt).
   • Implement a custom Hasher that routes to bcrypt/scrypt based on the column.
   • Rehash existing bcrypt users in batches (e.g., via a queue job).
3. Phase 3: Cutover
   • Update all Hash::make() calls to use scrypt.
   • Remove bcrypt fallback logic.

Compatibility

• Laravel Versions:
  • Tested on Laravel 8/9 (PHP 8.x). Avoid Laravel 5.x due to Symfony 2.x dependencies.
• Database:
  • Scrypt hashes are longer than bcrypt (e.g., $scrypt$N=16384$r=8$p=1$... vs. $2y$...).
  • Ensure the password column can accommodate 128+ character hashes.
• Third-Party Integrations:
  • APIs/auth services expecting bcrypt hashes will break. Update contracts or implement a translation layer.

Sequencing

1. Dependency Setup
   • Add tarcieri/scrypt-php to composer.json:

     "require": {
         "tarcieri/scrypt-php": "^2.0"
     }
     

   • Configure scrypt parameters in .env:

     SCRYPT_N=16384
     SCRYPT_R=8
     SCRYPT_P=1
     

2. Core Integration
   • Create a custom Hasher class (see Stack Fit).
   • Register the hasher in AuthServiceProvider:

     public function boot() {
         Hash::extend('scrypt', function ($app) {
             return new ScryptHasher($app['config']['hashing']);
         });
     }
     

3. Testing
   • Unit tests for hash generation/verification.
   • Load tests for login flows (simulate brute-force attempts).
4. Deployment
   • Roll out in stages (e.g., non-critical user groups first).

Operational Impact

Maintenance

• Long-Term Support:
  • Fork the bundle if upstream maintenance stalls. Prioritize:
    • PHP 8.x compatibility fixes.
    • Security updates for scrypt-php.
  • Monitor for CVE alerts in scrypt implementations.
• Configuration Drift:
  • Document N, r, p parameters and their security/performance tradeoffs.
  • Avoid hardcoding values; use .env for flexibility.

Support

• Troubleshooting:
  • Debugging scrypt failures may require deep dives into scrypt-php internals.
  • Prepare for support tickets on:
    • "Account locked out after migration" (hash mismatch).
    • "Login slow on shared hosting" (CPU/memory limits).
• Rollback Plan:
  • Maintain bcrypt as a fallback during migration.
  • Document steps to revert to bcrypt if scrypt becomes unstable.

Scaling

• Performance at Scale:
  • Scrypt’s memory usage (N parameter) may require:
    • Horizontal scaling (more servers) or vertical (higher-memory instances).
    • Rate-limiting login attempts to mitigate brute-force risks.
  • Consider caching verified hashes (e.g., Redis) for high-traffic apps.
• Database Impact:
  • Longer hashes increase storage usage. Monitor users table growth.

Failure Modes

• Security Risks:
  • Weak Parameters: Low N/r/p values reduce scrypt’s effectiveness. Validate defaults against OWASP guidelines.
  • Implementation Bugs: Pure-PHP scrypt is slower; ensure ext-sodium is unavailable if relying on it.
• Operational Risks:
  • Migration Failures: Batch rehashing may time out or lock tables. Use database transactions and retries.
  • Compatibility Issues: Third-party auth systems (e.g., OAuth providers) may reject scrypt hashes.
• User Impact:
  • Lockouts: Hash mismatches during