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 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.

📌 What’s the Issue?

The system does not mark a TOTP code as “used” after successful login.
Because of this, anyone can:

Enter the TOTP code in one browser
Reuse the same code in another browser or session
Successfully log in again before the 30-second interval ends

This makes it possible for an attacker to replay a valid code and bypass 2FA.

🧪 Steps to Reproduce

Enable 2FA (Google Authenticator).
Open Browser 1 → log in and reach the TOTP screen.
Open Browser 2 / Incognito → repeat the login and reach the same TOTP screen.
Open Google Authenticator → get the current 6-digit code.
Enter the code in Browser 1 → login succeeds.
Enter the same code in Browser 2 → login succeeds again.

The TOTP is accepted twice (or more), even though it should only be valid once.

🎯 Why This Matters

TOTP is designed to be a one-time password.
If a system allows reuse, it opens the door for:

Replay attacks
Unauthorized account access
Session hijacking
Increased risk when codes are intercepted or exposed

A valid TOTP code becomes far more dangerous when it can be used more than once.

🛠 Recommended Fix

Implement one-time use enforcement for each TOTP code:

Once a TOTP for a specific timestamp is successfully used, store it as “used.”
Reject any future attempt using the same timestamp/code combination—even if it’s within the same 30-second window.

In simple terms:

Don’t allow the same TOTP timestamp to pass validation more than once.

💬 Conclusion

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.