A team relies on IP-based login throttling and later sees abusive authentication continue from rapidly changing IPv6 clients.
Rate limiting appears to work but attackers still spray passwords because IPv6 privacy addresses defeat the IP-only key
Requests are throttled per address, yet abuse continues because the attacker rotates source addresses faster than the limit model expects.
Scenario
What to check first
- Identify the primary failure signal in the Wrong Rate-Limit Key scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Revisit the identity key behind throttling before only raising or lowering thresholds.
Questions worth viewing together
Community-field auth defense problem inspired by public discussions where IPv6 address rotation bypassed IP-only login throttling. IP-only throttling can be weak if the source identity rotates cheaply.
Teams often believe the limit is broken when the key choice is simply too narrow for the attack pattern.
Modern address rotation can make naive IP-based rate limiting feel effective while still being bypassed.
Similar cases seen in the field