Estoy imaginando un escenario en el que un atacante puede leer el tráfico entre un usuario y un servidor. El atacante toma la contraseña del usuario y el código 2fa que usaron. El atacante luego inicia sesión con esa información antes de que caduque el código 2fa.
¿Cómo se protege esto?
Puedes reutilizar la lista negra. Simplemente ahorre tiempo (o código) del inicio de sesión anterior y obligue al usuario a esperar hasta que se genere una nueva OTP. En general, los tokens TOTP se actualizan cada treinta segundos.
Puedes usar OTP basado en contador; la reutilización nunca ocurrirá ya que ambos dispositivos incrementan el contador.
Este ataque MitM contra 2FA no importa (en su mayoría). Si un atacante tiene la capacidad de interceptar las comunicaciones de texto sin formato entre el cliente y el servidor, simplemente puede robar la cookie de sesión cuando se envía de vuelta. El único lugar en el que marca la diferencia es si se requiere un código 2FA al cambiar la contraseña o al desactivar 2FA, en cuyo caso el atacante podría reproducir el código para hacerse cargo de la cuenta. Sin embargo, incluso si se evita la reproducción, tener la cookie de sesión y la contraseña le daría a un atacante acceso completo para hacer cualquier cosa que no requiera un código 2FA adicional.
Para evitar la reutilización de un código 2FA interceptado por otros medios (por ejemplo, interceptar sms / email), el servidor solo debe permitir el uso de un código una vez. Esto se puede hacer almacenando un código y enviándolo, luego eliminando el código una vez que se usa.
Para TOTP, la prevención de repetición se puede hacer almacenando la última ventana de autorización exitosa e impidiendo que el código de esa ventana (o ventanas anteriores) se vuelva a utilizar. El RFC simplemente requiere un uso único sin especificar ninguna implementación en particular:
El verificador NO DEBE aceptar el segundo intento de la OTP después de que se haya emitido la validación exitosa para la primera OTP, lo que garantiza el uso único de una OTP.
HOTP y U2F impiden la reproducción por diseño, HOTP mediante el uso de un contador y U2F debido a su uso de un método de desafío-respuesta.
Primero que todo: ¡No importa lo que debas usar TLS para cifrar el tráfico de la red en todas partes, lo que te protege de los sniffs de la red!
Un ataque no técnico y común en el uso de contraseñas es shoulder-surfing . Así que no estoy de acuerdo con otros que afirman que reutilizar OTP no es un problema.
Debe registrar el contador (para HOTP) o el intervalo de tiempo (para TOTP) de la última autenticación exitosa para evitar ataques de repetición y, de hecho, hacer un valor OTP una sola vez.
Para HOTP esto es obligatorio. Pero no todas las implementaciones del validador TOTP lo hacen porque también presenta un pequeño inconveniente para el usuario de esperar el siguiente paso de tiempo (generalmente 30+ segundos).
Si lo está implementando, le recomiendo que lea detenidamente las secciones de consideraciones de seguridad y requisitos de seguridad en RFC 4226 y / o RFC 6238 . Especialmente los aspectos de manejo seguro fuera de sincronización / condiciones de deriva son importantes. Definitivamente vale la pena pensar en esto.
En mi propia implementación, he vuelto a factorizar el manejo de errores para consumir siempre de manera confiable un valor OTP válido, significa contador de actualización o paso de tiempo, incluso si otras partes del proceso salieron mal (por ejemplo, contraseña incorrecta, etc.).
Lea otras preguntas en las etiquetas multi-factor replay-detection