Security vulnerabilities

Attached to Project: Security vulnerabilities
Opened by nhlimon - 18.10.2025
Last edited by cbay - 20.10.2025

Summary
The application applies rate limiting on failed login attempts per IP address, but does not combine this with account- or device-based throttling. An attacker can rotate IP addresses (using VPNs, proxies, or botnets) and continue brute-force or credential stuffing attempts against the same account, effectively bypassing the rate limit. This allows high-volume automated attacks that can lead to account takeover, credential stuffing success, and large-scale account enumeration.

Steps to Reproduce
In the alwaysdata.com application, choose a target account (e.g., victim@example.com).

From IP A, submit the maximum allowed failed login attempts until the application rate-limits further attempts from IP A. Record the response/status code.

Switch to IP B (use VPN, proxy, or other IP rotation technique).

Attempt to authenticate to the same target account using different password guesses. Observe that attempts from IP B are accepted and counted separately (rate limit not enforced per account).

Repeat with IP C, IP D, etc., and observe continued unrestricted attempts against the same account.

(Optional) Automate steps 2–4 from a list of rotating IPs to confirm large-scale brute-force is possible.

Expected secure behavior: The system should limit authentication attempts per account (or per account+device fingerprint) in addition to per-IP limits.
Observed insecure behavior: Authentication attempts continue after IP rotation; rate limiting is effectively bypassed.

Impact
Account Takeover (High): Continuous attempts across rotated IPs increase the probability of successfully brute-forcing a password or succeeding with credential stuffing.

Mass Credential Stuffing (High → Critical): Attackers can target many accounts at scale by cycling IPs, causing large-scale account compromise.

Recommended Fixes
Enforce account-based throttling (primary)

Track failed authentication attempts per account (email/username) and apply progressive throttling or temporary lockouts. Example policy: after 5 failed attempts for an account within 15 minutes, block further attempts for that account for 15 minutes.

Combine IP + account limits (defense-in-depth)

Use a hybrid key: limit_key = hash(account_id + ip) plus a separate limit_key = account_id. This reduces false positives while preventing IP-rotated attacks.