¿Pueden ocurrir inicios de sesión simultáneos cuando dos usuarios tienen información de autenticación de dos factores?

4

En una situación hipotética (por ejemplo, un programa de captura de pantalla o rootkit, donde, por cierto, un cambio de contraseña no hará ninguna diferencia) donde un atacante tiene su contraseña y ve la respuesta de dos factores al iniciar sesión con esa contraseña (Ya sea a través de SMS o un sistema más robusto como iCloud a iPhone de dos factores), ¿existe una situación en la que ambos usuarios, con contraseña y dos factores, puedan iniciar sesión en un sistema al mismo tiempo?

En aras del ejemplo, utilicemos el sistema iCloud de Apple, iniciando sesión en un Macbook, recibiendo un código de dos factores en un iPhone (no a través de SMS, a través de su sistema de dos factores basado en la nube). Tanto el portátil como el teléfono están enraizados, por lo que ambos son visibles. ¿Se puede utilizar la información de inicio de sesión para iniciar sesión en más de un lugar simultáneamente?

    
pregunta rcd 24.12.2015 - 08:02
fuente

2 respuestas

6

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

    
respondido por el chexum 24.12.2015 - 11:25
fuente
5

Es posible tener dos sesiones de inicio de sesión, pero requerirá dos instancias de los factores primero y segundo.

El segundo factor generalmente es un código de uso único, que caducará después de su uso. También puede agotar el tiempo de espera después de un período de tiempo específico si no se utiliza

Por ejemplo; Si el primer factor es un nombre de usuario / contraseña, será el mismo para ambas sesiones de inicio de sesión.

Si el segundo factor es un token, en forma de un código único de 6 dígitos. Ambos inicios de sesión necesitarán el nombre de usuario / contraseña común y su propia instancia específica del código único de 6 dígitos

Esto es, por supuesto, una generalización y diferentes sistemas tendrán sus propios matices.

Incidentalmente, en un experimento no científico, intenté usar el código de un intento de inicio de sesión de Google en un intento de inicio de sesión separado para ver si el código era portátil entre sesiones y fue exitoso.

    
respondido por el TheJulyPlot 24.12.2015 - 10:58
fuente

Lea otras preguntas en las etiquetas