Depende del tipo de método OTP y los detalles de la implementación. Mientras que [RFC4226] [1] (la OTP basada en el contador) puede entenderse que prohíbe la reutilización, como dice:
el valor del contador del servidor solo se incrementa después de un HOTP exitoso
autenticación
Pero eso puede no ser una garantía de que no hay una ventana de tiempo en la que se pueda utilizar el mismo token de HOTP: los servidores de autenticación multiproceso, con acceso simultáneo a la base de datos, pueden pasar por alto este detalle.
También está describiendo que:
RP3 - P DEBE implementarse en un canal seguro para proteger la privacidad de los usuarios y evitar los ataques de repetición.
¡Lo que implica que no lo consideran propiedad del protocolo para protegerse contra tokens reutilizados!
De manera similar, para OTP basado en tiempo [RFC6238] [2] explica que es una buena protección contra los ataques para reducir la ventana de tiempo cuando un token es válido. Pero se menciona que el token se consume , lo que para algunos puede implicar que no se puede consumir de nuevo.
Primero, un tamaño de paso de tiempo más grande expone una ventana más grande para atacar. Cuando se genera una OTP y se expone a un tercero antes de que se consuma, el tercero puede consumir la OTP dentro de la ventana de un período de tiempo.
Yo, personalmente, no creo que un segundo factor copiado deba ser válido, pero esto no es necesariamente lo que dicen los estándares, por lo que puede haber variaciones sobre cómo se interpreta esto. Es posible que otros proveedores de 2FA ni siquiera se adhieran a ninguna de las normas, y pueden tener requisitos más estrictos o más flexibles. Permítanme también señalar que puede ser difícil implementar un método confiable para bloquear todo, excepto el primer uso de un token dentro de redes ampliamente distribuidas, para todos los casos.
Actualizar: ahora que lo pienso, puedo ver dos formas adicionales de evitar el acceso con OTP duplicadas, una está en la preparación: asegurarme de que solo haya una contraseña de inicio de sesión que esté en progreso de aceptar una OTP hasta el tiempo de espera de autenticación. El otro es invalidar la sesión ya otorgada, además de la duplicada. Esto puede ser fácil en un servicio basado en web, pero no es tan conveniente con un acceso de shell de computadora.
También debe considerarse que no puede estar seguro de que el usuario válido sea el primero, por lo que también puede ser un obstáculo para ellos. En el caso de un MITM verdadero, el atacante puede incluso detener los intentos genuinos por ellos para que no pueda haber una notificación en el mismo canal.
Como puede ver, no es tan sencillo aceptar o no aceptar la OTP duplicada: debe considerar al usuario del servicio, cómo pueden ingresar a esta situación y cómo serán los menos perjudicados o mejor atendidos . Quizás es por esto que los estándares no discuten estos detalles y se lo dejan a usted.
[1]: enlace RFC4226-HOTP
[2]: enlace RFC6238-TOTP