Ashish Pathak Sec

Two-factor authentication (2FA) is supposed to be one of the strongest layers of account protection. But during routine testing, I discovered a serious issue: the system allows the same Google Authenticator (TOTP) code to be used multiple times, even across different login sessions.
This completely breaks the “one-time” nature of one-time passwords. <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVcVUdFVCnU1lkS4LTnDkvuxYu2gG7eDnq5kHueG9Vi9RvDEcHVqXcsNBVvC4M5Z7RWa1HE5Nt06Snnls7poB9AMb1JwedK0t2xyeKpQ-9WGqRB3wCH4-aACGz0t_XHalEEyT-4REfjUuKpWbpaA80B00W_5n5Lb6dMni_G6QiMAr6TJ08aeGvJoTAKRc/s1024/Gemini_Generated_Image_th9l8hth9l8hth9l.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1024" data-original-width="1024" height="430" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVcVUdFVCnU1lkS4LTnDkvuxYu2gG7eDnq5kHueG9Vi9RvDEcHVqXcsNBVvC4M5Z7RWa1HE5Nt06Snnls7poB9AMb1JwedK0t2xyeKpQ-9WGqRB3wCH4-aACGz0t_XHalEEyT-4REfjUuKpWbpaA80B00W_5n5Lb6dMni_G6QiMAr6TJ08aeGvJoTAKRc/w430-h430/Gemini_Generated_Image_th9l8hth9l8hth9l.png" width="430" /></a></div>  
<hr data-end="545" data-start="542" />
<h2 data-end="574" data-start="547">📌 What’s the Issue?</h2>
The system does not mark a TOTP code as “used” after successful login. 
Because of this, anyone can:
<ul data-end="838" data-start="679"><li data-end="717" data-start="679">
Enter the TOTP code in one browser
</li><li data-end="773" data-start="718">
Reuse the same code in another browser or session
</li><li data-end="838" data-start="774">
Successfully log in again before the 30-second interval ends
</li></ul>
This makes it possible for an attacker to replay a valid code and bypass 2FA.
<hr data-end="922" data-start="919" />
<h2 data-end="952" data-start="924">🧪 Steps to Reproduce</h2>
<ol data-end="1318" data-start="954"><li data-end="993" data-start="954">
Enable 2FA (Google Authenticator).
</li><li data-end="1053" data-start="994">
Open Browser 1 → log in and reach the TOTP screen.
</li><li data-end="1140" data-start="1054">
Open Browser 2 / Incognito → repeat the login and reach the same TOTP screen.
</li><li data-end="1203" data-start="1141">
Open Google Authenticator → get the current 6-digit code.
</li><li data-end="1254" data-start="1204">
Enter the code in Browser 1 → login succeeds.
</li><li data-end="1318" data-start="1255">
Enter the same code in Browser 2 → login succeeds again.
</li></ol>
The TOTP is accepted twice (or more), even though it should only be valid once.
<hr data-end="1404" data-start="1401" />
<h2 data-end="1432" data-start="1406">🎯 Why This Matters</h2>
TOTP is designed to be a one-time password. 
If a system allows reuse, it opens the door for:
<ul data-end="1663" data-start="1534"><li data-end="1552" data-start="1534">
Replay attacks
</li><li data-end="1584" data-start="1553">
Unauthorized account access
</li><li data-end="1606" data-start="1585">
Session hijacking
</li><li data-end="1663" data-start="1607">
Increased risk when codes are intercepted or exposed
</li></ul>
A valid TOTP code becomes far more dangerous when it can be used more than once.
<hr data-end="1750" data-start="1747" />
<h2 data-end="1777" data-start="1752">🛠 Recommended Fix</h2>
Implement one-time use enforcement for each TOTP code:
<ul data-end="2038" data-start="1839"><li data-end="1921" data-start="1839">
Once a TOTP for a specific timestamp is successfully used, store it as “used.”
</li><li data-end="2038" data-start="1922">
Reject any future attempt using the same timestamp/code combination—even if it’s within the same 30-second window.
</li></ul>
In simple terms:
<blockquote data-end="2135" data-start="2059">
Don’t allow the same TOTP timestamp to pass validation more than once.
</blockquote>
<hr data-end="2140" data-start="2137" />
<h2 data-end="2162" data-start="2142">💬 Conclusion</h2>
This vulnerability weakens the security of an otherwise strong 2FA system. By allowing TOTP reuse, the door is left open for attackers to exploit replay attacks and gain unauthorized access.
Fixing this requires a straightforward change: treat each TOTP as truly one-time.

Critical 2FA Vulnerability: Reusable TOTP Codes Allow Unauthorized Access

Two-factor authentication (2FA) is supposed to be one of the strongest layers of account protection. But during routine testing, I discove...

Rate limiting is one of the oldest and most widely used defenses in web security. It’s supposed to help protect login forms, password-reset flows, and other sensitive endpoints from abuse. But as the internet evolves, so do the tools attackers use—and some longstanding defenses no longer hold up the way they once did. <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjV7qXKbaSawskWlOECRqG7qdufpRslL49mG3pP-Zt5Sixo_nkXaiwvuVZwAUjGo9Lol1FMo5Be_i9tFLe2VvmvSK4LAv6F4_VjjffKFtbyBhd8iWApCedmhXqBEuLXLpi47lnLgsMPbW_2lGSN3kVJaXABtk_etzbTWQzqZs0tE9VbfRQqn0gn1ajNRXM/s1024/Gemini_Generated_Image_ab516pab516pab51.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1024" data-original-width="1024" height="530" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjV7qXKbaSawskWlOECRqG7qdufpRslL49mG3pP-Zt5Sixo_nkXaiwvuVZwAUjGo9Lol1FMo5Be_i9tFLe2VvmvSK4LAv6F4_VjjffKFtbyBhd8iWApCedmhXqBEuLXLpi47lnLgsMPbW_2lGSN3kVJaXABtk_etzbTWQzqZs0tE9VbfRQqn0gn1ajNRXM/w530-h530/Gemini_Generated_Image_ab516pab516pab51.png" width="530" /></a></div>  
Recently, while testing the security of a “Forgot Password” flow, I uncovered a flaw that highlights just how outdated IP-based rate limiting has become. With nothing more than basic IP rotation techniques, I was able to bypass the application’s throttling entirely and send unlimited password-reset requests to any target email address.
This post walks through what I discovered, why it matters, and why developers need to rethink how they design defenses for critical authentication endpoints.
<hr data-end="1099" data-start="1096" />
<h2 data-end="1152" data-start="1101">The Problem With IP-Based Throttling in 2025</h2>
Most applications today still follow a familiar pattern:
<ol data-end="1394" data-start="1212"><li data-end="1273" data-start="1212">
A user enters their email into the “Forgot Password” form.
</li><li data-end="1307" data-start="1274">
The server sends a reset link.
</li><li data-end="1394" data-start="1308">
To prevent abuse, the server limits how many requests can be made from the same IP.
</li></ol>
At first glance, this seems reasonable. But in practice, attackers have countless ways to cycle through IPs:
<ul data-end="1730" data-start="1506"><li data-end="1533" data-start="1506">
VPNs and proxy services
</li><li data-end="1561" data-start="1534">
Shared hosting networks
</li><li data-end="1614" data-start="1562">
Cloud platforms like AWS, DigitalOcean, or Vultr
</li><li data-end="1678" data-start="1615">
IPv6 subnets that come with trillions of unique addresses
</li><li data-end="1730" data-start="1679">
Botnets of compromised devices around the world
</li></ul>
What does this mean? 
It means that IP-based rate limiting no longer meaningfully limits anything.
<hr data-end="1840" data-start="1837" />
<h2 data-end="1879" data-start="1842">What I Observed During Testing</h2>
My test was simple:
<ol data-end="2078" data-start="1902"><li data-end="1964" data-start="1902">
Submit multiple password-reset requests for the same email.
</li><li data-end="2047" data-start="1965">
Wait until the server returns a “too many attempts” or “rate limited” response.
</li><li data-end="2064" data-start="2048">
Change my IP.
</li><li data-end="2078" data-start="2065">
Try again.
</li></ol>
Each time I switched IPs, the server completely reset the throttle. I was treated as a brand-new user—able to send more password-reset emails instantly.
It didn’t matter that I was requesting resets for the same email, in the same pattern, seconds apart. The only thing the server cared about was the client IP.
This meant that:
<ul data-end="2601" data-start="2412"><li data-end="2462" data-start="2412">
An attacker could send unlimited reset emails.
</li><li data-end="2511" data-start="2463">
A user could be mail-bombed into submission.
</li><li data-end="2601" data-start="2512">
The underlying authentication endpoint could be brute-forced across thousands of IPs.
</li></ul>
In short: the system’s main line of defense could be bypassed with a technique available to anyone with a VPN subscription.
<hr data-end="2733" data-start="2730" />
<h2 data-end="2777" data-start="2735">Real-World Abuse Isn’t Hypothetical</h2>
This kind of vulnerability has precedent. One of the most infamous examples was the 2015 Apple “Celebgate” incident, where attackers brute-forced credentials against an Apple endpoint that relied heavily on IP-based throttling.
The takeaway from that event—and countless others since—is clear:
<blockquote data-end="3164" data-start="3075">
IP-based rate limiting is not a modern security control. It’s a speed bump at best.
</blockquote>
Yet many applications still depend on it as if it were a reliable barrier.
<hr data-end="3245" data-start="3242" />
<h2 data-end="3280" data-start="3247">Why It Matters: The Impact</h2>
This loophole opens the door to a range of abusive behaviors:
<h3 data-end="3368" data-start="3345">1. Mail Bombing</h3>
A malicious actor could bombard a victim’s inbox with hundreds or thousands of password-reset emails. 
This can:
<ul data-end="3590" data-start="3484"><li data-end="3520" data-start="3484">
overwhelm and frustrate the user
</li><li data-end="3556" data-start="3521">
hide legitimate security alerts
</li><li data-end="3590" data-start="3557">
degrade trust in the platform
</li></ul>
<h3 data-end="3626" data-start="3592">2. Distributed Brute Force</h3>
Login or reset endpoints that rely solely on IP throttling are particularly vulnerable. 
Attackers can distribute attempts across many IPs and avoid triggering any alarms.
<h3 data-end="3834" data-start="3801">3. User Experience Damage</h3>
If users regularly receive unsolicited reset emails, they’ll perceive the platform as insecure—even if their account hasn’t been compromised.
<h3 data-end="4015" data-start="3978">4. Potential Account Takeover</h3>
If combined with weak tokens, predictable reset flows, or other vulnerabilities, this issue could escalate to full account compromise.
<hr data-end="4155" data-start="4152" />
<h2 data-end="4197" data-start="4157">Why This Is So Easy for Attackers</h2>
The reality is that rotating IP addresses is now trivial:
<ul data-end="4518" data-start="4258"><li data-end="4375" data-start="4258">
Many cloud providers offer full /64 IPv6 ranges, giving attackers access to 18 quintillion addresses per VPS.
</li><li data-end="4442" data-start="4376">
Modern botnets contain millions of globally distributed devices.
</li><li data-end="4518" data-start="4443">
Proxy and VPN networks offer automated IP rotation as a standard feature.
</li></ul>
A security control that assumes “one user = one IP” simply doesn’t reflect the state of the internet anymore.
<hr data-end="4634" data-start="4631" />
<h2 data-end="4692" data-start="4636">How to Fix It: Modern Defenses That Actually Work</h2>
To meaningfully protect password-reset flows and similar endpoints, developers need to adopt multi-layered, identity-aware mitigation strategies.
Here are the most effective options:
<h3 data-end="4910" data-start="4881">1. CAPTCHA Challenges</h3>
A CAPTCHA (invisible or user-facing) prevents automated mass requests even across thousands of IPs.
<h3 data-end="5062" data-start="5012">2. Rate Limiting Based on the Target Email</h3>
Instead of only limiting per-IP, also limit how often each email can receive a reset.
<h3 data-end="5195" data-start="5154">3. Behavioral and Velocity Checks</h3>
Look beyond IPs:
<ul data-end="5311" data-start="5213"><li data-end="5237" data-start="5213">
browser fingerprints
</li><li data-end="5258" data-start="5238">
request velocity
</li><li data-end="5289" data-start="5259">
unusual patterns or bursts
</li><li data-end="5311" data-start="5290">
device reputation
</li></ul>
<h3 data-end="5353" data-start="5313">4. Honeypots or Invisible Fields</h3>
Bots often fill fields humans never touch—this is an easy way to detect automated abuse.
<h3 data-end="5479" data-start="5444">5. Abuse Detection Services</h3>
Modern WAFs (Web Application Firewalls) and anti-bot platforms use IP reputation, machine learning, and behavioral signals that far outperform raw IP throttling.
<h3 data-end="5665" data-start="5643">6. User Alerts</h3>
Notify users when multiple reset attempts occur. Visibility itself is a form of defense.

IP Rotation Loophole That Breaks Traditional Rate Limiting

Rate limiting is one of the oldest and most widely used defenses in web security. It’s supposed to help protect login forms, password-rese...

Ashish Pathak Sec

Critical 2FA Vulnerability: Reusable TOTP Codes Allow Unauthorized Access

IP Rotation Loophole That Breaks Traditional Rate Limiting

Populars

Archive