Extended Login Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for account-takeover defense. The package models a specific, defensible pattern: track failed login attempts per account/IP, then escalate to a CAPTCHA challenge after a threshold. This is directly useful as a reference design when scoping a brute-force / credential-stuffing mitigation epic, even if you don't adopt the code.
• Build vs. buy vs. framework-native. The strongest decision this package informs is "none of the above." Its core capability overlaps almost entirely with what Laravel already ships (RateLimiter, throttle middleware, Fortify's login throttling) and what Symfony ships (login_throttling in the SecurityBundle). The package's only differentiator is the CAPTCHA escalation step — roughly a controller listener plus a challenge view.
• UX tradeoff for authentication friction. Choosing progressive challenge (silent for N attempts, then human verification) versus unconditional CAPTCHA is a product call with measurable impact on login conversion, mobile completion rates, and accessibility. This package encodes the progressive model, which is the one worth defending.
• Security roadmap prioritization. If your backlog has "rate limit the login endpoint" sitting unestimated because it looks like a third-party integration, this package is evidence it's a small, self-contained task — likely a sprint-sized item rather than a vendor evaluation.
• Not a fit for: SSO decisions, MFA strategy, password policy, or session management. Scope is narrow: failed-attempt counting plus a challenge gate.

When to Consider This Package

Adoption criteria — and note that all of them must hold simultaneously, which is unlikely:

• You are on Symfony, not Laravel. Despite being catalogued here as a Laravel/PHP package, this is a Symfony bundle (ExtendedLoginBundle, bundle-style service config). It will not drop into a Laravel app. That alone disqualifies it for most Laravel teams before any other consideration.
• You are pinned to an older Symfony version whose SecurityBundle lacks native login_throttling (pre-5.2), and you cannot upgrade.
• You need a CAPTCHA gate specifically, and you are comfortable adopting a dormant dependency into your authentication path.

Reasons to look elsewhere — several of which are decisive on their own:

• Maintenance risk is disqualifying for auth code. Zero stars, zero dependents, last release July 2020. A security-adjacent component with no release in ~5 years means no CVE response, no compatibility patches, and no community signal that anyone has audited it. Authentication code is precisely where "unmaintained but probably fine" is not an acceptable posture.
• No adoption evidence. Zero dependents means zero production feedback loops. You would be the first real user, debugging alone.
• Framework-native alternatives are strictly better. Use Laravel's RateLimiter/throttle on the login route plus a maintained CAPTCHA driver (reCAPTCHA/hCaptcha/Turnstile), or Symfony's login_throttling with a maintained CAPTCHA bundle. You get the same behavior with active security support and no orphan dependency.
• Prefer vendor-maintained CAPTCHA SDKs. CAPTCHA providers change APIs and their client libraries matter; pick one with a current release cadence.

Recommendation: build in-house on framework primitives. The scope is small — a failed-attempt counter, a threshold, a challenge gate, and a reset-on-success. Owning ~100 lines of well-tested code beats owning an unmaintained dependency in your auth path.

How to Pitch It (Stakeholders)

For executives: We evaluated a third-party add-on for blocking automated login attacks. It implements the right pattern — silently tolerate a few failed attempts, then require human verification — but the package itself is effectively abandoned: no updates since 2020, no known users, and it targets a different PHP framework than ours. Putting unmaintained code in the authentication path is an unacceptable risk. Recommendation: implement the same behavior in-house on framework components we already maintain. Estimated effort is small — days, not weeks — and it delivers the security outcome without adding a dependency we'd have to babysit.

For engineering: Do not adopt. It's a Symfony bundle, not Laravel-compatible; last release 2020; zero dependents; no security maintenance. The behavior it describes is worth copying, not the code: rate-limit the login route with the framework's native limiter, count failures per account and per IP, escalate to a CAPTCHA (Turnstile/hCaptcha — pick a maintained SDK) above threshold, reset the counter on successful auth, and log the escalation events so we can tune the threshold. Keep the challenge progressive so normal users never see it, and verify accessibility of the challenge before shipping.