Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Security] Fix local login rate limiter to key on username only#63997

Closed
ayyoub-afwallah wants to merge 1 commit into
symfony:6.4from
ayyoub-afwallah:fix/low-login-rate-limit
Closed

[Security] Fix local login rate limiter to key on username only#63997
ayyoub-afwallah wants to merge 1 commit into
symfony:6.4from
ayyoub-afwallah:fix/low-login-rate-limit

Conversation

@ayyoub-afwallah
Copy link
Copy Markdown
Contributor

@ayyoub-afwallah ayyoub-afwallah commented Apr 19, 2026

Q A
Branch? 6.4
Bug fix? yes
New feature? no
Deprecations? no
Issues Fix #61932
License MIT

Using the client IP in the local login rate limiter exposes the risk of brute force attacks (bypassed by rotating IPs).

This patch fixes it by relying on username only.

@nicolas-grekas
Copy link
Copy Markdown
Member

On the other side, this makes it trivial to rate-limit an account from any IP.
I'd rather not change this and close the linked issue as won't fix /cc @Seldaek

@Seldaek
Copy link
Copy Markdown
Member

Seldaek commented Apr 21, 2026

Yeah i can see that. It boils down to what is the greatest risk and what does the most damage I guess. I'd say ip based restrictions are less and less useful because botnets are widely available and ipv6 let's you have a million ips easily. So the main thing ip based rate limiting fixes is that security researchers stop sending reports about lack of rate limiting..

Of course I may be wrong 🤷🏻‍♂️

@nicolas-grekas
Copy link
Copy Markdown
Member

At least it protects against me hitting F5 in a loop:D

@ayyoub-afwallah
Copy link
Copy Markdown
Contributor Author

i think a locked out account is a temporary problem, a hacked one isn't. the only downside is that it stays locked as long as it's under attack

@nicolas-grekas
Copy link
Copy Markdown
Member

Thinking more about it: I agree the IP dimension alone is weak (botnets, IPv6), but I don't think dropping it is the answer. It just swaps one attack (distributed brute-force) for another (targeted account-lockout DoS, trivially mountable from anywhere). For a default shipped to every Symfony app, the second failure mode feels worse than the first: a sustained attacker keeps named accounts (admins, support, on-call) frozen indefinitely.

We should add a third limiter keyed on username only, so the chain becomes: 1. IP only, 2. username+IP, 3. username only.

That'd cover the botnet case from the issue without making lockout-DoS a one-liner. Not perfect (a patient attacker can still saturate #3), but a real hardening rather than a tradeoff swap.

Also worth noting: this is a behavior change, so even if we go this route I'd target 8.x rather than 6.4.

Closing therefor. Thanks for submitting.

symfony-splitter pushed a commit to symfony/security-http that referenced this pull request May 4, 2026
…t brute-force attacks (ayyoub-afwallah)

This PR was merged into the 8.1 branch.

Discussion
----------

[Security] Add per-username login rate-limit to prevent brute-force attacks

| Q             | A
| ------------- | ---
| Branch?       | 8.1
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Issues        | Fix #61932
| License       | MIT

Adds a third rate-limiter to DefaultLoginRateLimiter as suggested in symfony/symfony#63997 (comment)

Commits
-------

a84ec30c21a [Security] Add per-username login rate-limit to prevent brute-force attacks
nicolas-grekas added a commit that referenced this pull request May 4, 2026
…t brute-force attacks (ayyoub-afwallah)

This PR was merged into the 8.1 branch.

Discussion
----------

[Security] Add per-username login rate-limit to prevent brute-force attacks

| Q             | A
| ------------- | ---
| Branch?       | 8.1
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Issues        | Fix #61932
| License       | MIT

Adds a third rate-limiter to DefaultLoginRateLimiter as suggested in #63997 (comment)

Commits
-------

a84ec30 [Security] Add per-username login rate-limit to prevent brute-force attacks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants