I'm imagining a scenario where an attacker can read traffic between a user and a server. The attacker grabs the user's password and the 2fa code they used. The attacker then logs in with that information before the 2fa code expires.
How is this protected against?
You can black list reuse. Simply save time (or code) of previous login, and force the user to wait until new OTP is generated. Generally TOTP tokens are updated every thirty seconds.
You can use counter based OTP; re-use will never occur as both devices increment the counter.
This MitM attack against 2FA doesn't matter (mostly). If an attacker has the ability to intercept plaintext communications between the client and server, they can simply steal the session cookie when it's sent back. The one place this makes a difference is if a 2FA code is required when changing the password or disabling 2FA, in which case the attacker could replay the code to take over the account. Even if replay is prevented though, having the session cookie and password would give an attacker full access to do anything not requiring an additional 2FA code.
To prevent reuse of a 2FA code intercepted by other means (e.g. intercepting sms/email), the server should only allow a code to be used once. This can be done by storing a code and sending it, then deleting the code once used.
For TOTP, replay prevention can be done by storing the last successful authorization window and preventing the code from that window (or previous windows) from being used again. The RFC simply requires one time use without specifying any particular implementation:
The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP.
HOTP and U2F prevent replay by design, HOTP by use of a counter and U2F due to its use of a challenge-response method.
First of all: No matter what you should use TLS for encrypting the network traffic everywhere which protects you from network sniffing!
A non-technical and common attack on password use is shoulder-surfing. So I disagree with others claiming that reusing OTP is not an issue.
You have to record the counter (for HOTP) or the time-step (for TOTP) of the last successful authentication to prevent replay attacks and actually make an OTP value one-time.
For HOTP this is mandatory. But not every TOTP validator implementation does that because it also introduces a small user inconvenience to wait for the next time-step (usually 30+ secs).
If you're implementing it I'd strongly recommend to carefully read security considerations and security requirements sections in RFC 4226 and/or RFC 6238. Especially the aspects of secure handling out-of-sync / drifting conditions are important. It's definitely worth to put some thinking into this.
In my own implementation I've re-factored error handling recently to always reliably consume a valid OTP value, means update counter or time-step, even if other parts of the processing went wrong (e.g. wrong password etc.).
