Login Protect Bundle Laravel Package

Technical Evaluation

Evidence base and confidence

This assessment is based on the package name (tourze/login-protect-bundle), its version trajectory (1.0.0 → 1.0.1), and standard conventions for PHP login-protection libraries. No source review, dependency manifest, or prior assessment is available, and the 1.0.1 release notes contain only an auto-generated changelog link with no described changes. Treat architecture claims below as hypotheses to validate in a spike, not findings.

Architecture fit

• The package name indicates login protection: failed-attempt tracking, account/IP lockout, and throttling. This duplicates capability already shipped in Laravel (Illuminate\Cache\RateLimiter, ThrottlesLogins, Fortify's throttleLogin, and the Lockout event). The package must justify itself on the delta — typically per-account lockout persistence, IP reputation, audit trail, or alerting.
• "Bundle" is a Symfony convention, not Laravel. There is a real possibility this is a Symfony bundle that is merely installable in a Laravel app rather than a Laravel-native package. That distinction drives most of the integration cost below.
• Integration surface, if Laravel-native, should be auth events (Illuminate\Auth\Events\Failed, Lockout, Login) or a guard middleware. If it is Symfony-shaped (EventSubscriber, services.yaml), it needs an adapter and will not benefit from Laravel's container auto-resolution.

Integration feasibility

• Straightforward if it ships a service provider with package auto-discovery, a publishable config, and a migration for an attempt-log table.
• Moderate-to-high effort if it requires manual wiring of listeners or carries Symfony components into the container. Watch for a transitive symfony/* dependency tree bloating the app.
• Verify the storage backend early: cache-based (cheap, volatile, Redis/array dependent) versus database-backed (durable, adds write load on every failed login). This is the single largest determinant of both feasibility and production risk.

Technical risk

• Release opacity (high). A patch release with no described changes means we cannot assess whether 1.0.1 is a bug fix, a security fix, or a metadata-only tag. We must diff 1.0.0...1.0.1 ourselves before adopting.
• Maintainer concentration (medium-high). Single-vendor package, early versioning (1.x), no visible backing. Security-adjacent code from a small maintainer needs an internal code review, not just a version pin.
• Security-critical domain (high). Auth lockout logic is a high-blast-radius component. A defect here is either an auth bypass or a login-denial outage.
• Semantic versioning trust (medium). At 1.0.x, minor and patch releases may still carry behavioral changes.

Key questions for the maintainer / spike

1. What specifically changed in 1.0.1, and was any of it security-relevant?
2. Is this Laravel-native (illuminate/* requirements, service provider) or a Symfony bundle?
3. Which storage drivers are supported, and what is the default?
4. On storage failure, does the library fail open (login allowed) or fail closed (login denied)? Is that configurable?
5. Does lockout key on account, IP, IP+account, or device? How does it behave behind a load balancer / trusted proxies?
6. Is there protection against lockout-as-DoS (attacker deliberately locking out known users)?
7. Test coverage, CI status, license, and security disclosure process?

Integration Approach

Stack fit

• Confirm PHP and Laravel version support against our current runtime before any commitment. If our apps are on Laravel 11/12 with PHP 8.2+, older-style packages frequently fail on container and config resolution.
• Confirm the cache store assumption. Our production cache is Redis-backed and shared across nodes; a package assuming a per-node array store will produce inconsistent lockout state.
• Confirm it does not conflict with existing throttling in Fortify/Breeze. Double-throttling produces confusing UX and unpredictable lockout windows.

Migration path

• Do not rip out existing throttling. Run the package in log-only / shadow mode first: record what it would have blocked while the incumbent control remains authoritative. Compare decisions for one to two weeks.
• If we are replacing bespoke logic, map old thresholds to new ones explicitly and document the change; lockout semantics are user-visible and generate support tickets.
• Keep a config-level kill switch so the package can be disabled without a deploy.

Compatibility

• Validate against every auth entry point we expose: web session login, API token/password grant, admin panel, and any SSO fallback.
• Check trusted-proxy and X-Forwarded-For handling against our ingress configuration — IP-based logic is wrong by default behind a proxy.
• Verify migration/additive schema changes are reversible and safe to run on a live database.

Sequencing

1. Spike (3–5 days): read the 1.0.0→1.0.1 diff, review source, install in a scratch app, confirm Laravel-native behavior.
2. Shadow mode (1–2 weeks): non-authoritative logging in staging, then one low-risk production endpoint.
3. Enforce, single surface: enable on the lowest-traffic auth path; monitor false-positive lockouts.
4. Enforce, all surfaces: roll out remaining endpoints behind a feature flag.
5. Decommission legacy throttling only after a full release cycle of clean behavior.

Operational Impact

Maintenance

• Version-pin exactly and upgrade deliberately. With no release notes, every bump requires a manual diff review — budget recurring time for this, not a one-off.
• An empty changelog is itself an operational cost: it shifts verification work onto us permanently.
• Watch for framework-version drift; small packages often lag Laravel majors by several months.

Support

• No commercial SLA. Support is GitHub issues with unknown responsiveness. Requires a named internal owner who can read the source.
• Establish an internal fork-or-patch contingency before adoption; assume we may have to carry a patch for a Laravel compatibility fix.

Scaling

• Cache/Redis-backed counters scale cleanly; database-backed counters add a write on every failed login — a meaningful load increase during credential-stuffing attacks, precisely when the system is already under stress. Benchmark at expected attack volume, not at baseline.
• Per-request overhead should be sub-millisecond; verify it is not adding a synchronous external call to the auth path.
• Multi-region deployments need a shared counter store, or lockout state fragments per region.

Failure modes

• Store unavailable → fail open (security regression) or fail closed (total login outage). Must be an explicit, documented decision. Default fail-closed is safer for security but is a self-inflicted availability risk; fail-open silently disables protection.
• Lockout-as-DoS: if keyed on account only, an attacker locks out real users at will. Needs IP+account keying, progressive delays, or CAPTCHA escalation.
• Proxy/NAT misconfiguration: shared egress IPs cause mass false-positive lockouts affecting an entire customer site.
• Multi-node inconsistency: per-node counters let attackers multiply their attempt budget by the number of nodes.
• Silent bypass: if the package registers listeners that do not fire on our custom guard or API auth path, protection is absent with no error to alert on. Add a synthetic canary test.

Ramp-up

• Low for a mid-level Laravel developer: roughly 3–5 days to spike, plus security review time.
• Add explicit time for a security engineer to review the lockout algorithm and failure-mode behavior — this is the highest-value review hour in the whole effort.
• Documentation burden is on us: with no upstream notes, we should write the internal runbook covering thresholds, kill switch, and fail-mode behavior.

Recommendation (provisional)

Adopt only after the spike confirms it is Laravel-native, resolves whether 1.0.1 is security-relevant, and settles the fail-open/fail-closed question. Absent a clear capability delta over Laravel's built-in rate limiting, the maintenance and review overhead likely outweighs the benefit.