2FA basado en la aplicación versus 2FA basado en el hardware

3

¿Cómo se comparan las aplicaciones como Symantec VIP / Okta Verify e implementaciones similares con el uso de un token de autenticación de hardware como los dispositivos U2F recientes?

¿Qué tan real es la posibilidad de que un sistema Android sea secuestrado y que se extraigan tokens de autenticación de la aplicación 2FA o que se extraigan claves secretas?

Además de no necesitar otro dispositivo, ¿hay otras ventajas para 2FA basado en aplicaciones?

Dado que con 2FA basado en la aplicación usted autentica una solicitud o sesión de inicio de sesión en tiempo real, ¿no es vulnerable a los ataques de phishing de reproducción de autenticación en tiempo real?

Editar: Parece que esto se responde aquí ¿Puede un smartphone ser visto estrictamente como el factor 'algo que posee' para 2FA cuando no tiene capacidad de token de hardware como las tarjetas inteligentes?

    
pregunta Ricky 20.10.2017 - 03:54
fuente

2 respuestas

2

Echa un vistazo a esta respuesta aquí para obtener más detalles. Pero aquí están los bits más destacados para su pregunta:

El problema con 2-factor implementado por Symantec VIP y Okta Verify tiene menos que ver con el hecho de que se implementa en el software, y mucho más con el hecho de que el código puede ser interceptado.

En este sentido, Symantec VIP, Okta Verify y RSA SecurID están en el mismo barco que Google Authenticator; ninguno de ellos lo protegerá contra el phishing porque la misma técnica que utiliza el atacante para obtener su contraseña también se puede utilizar para obtener su código de segundo factor; por lo general, al escribirlo en una página de inicio de sesión falsa.

Pero U2F es diferente.

Con U2F, no escribe una contraseña de un solo uso para mostrar que tiene su token. En cambio, el navegador se comunica directamente con el token de hardware, y parte del proceso es que el navegador le dice al token de hardware el nombre de host del sitio que solicita la identificación, y las identidades de 2FA están vinculadas al host individual. Y el navegador (a diferencia del usuario) no puede ser engañado respecto a qué host solicita autenticación porque el navegador comprueba el certificado TLS.

Esto significa que el sitio web de un atacante no puede obtener el código del segundo factor correcto, y significa que incluso si un atacante de ingeniería social inteligente logró engañar a un usuario para que entregue su contraseña, el usuario no puede abandona su código del segundo factor.

El token del segundo factor SÓLO se puede usar si el navegador se está comunicando con el sitio correcto, y solo si el navegador está físicamente conectado al token U2F. Esto elimina prácticamente cualquier ataque que no implique el robo físico del hardware de la víctima.

U2F podría implementarse (y ha estado) en el software, por lo que depende del software de su computadora en lugar de un dispositivo físico. Esto es aún mejor que el 2FA basado en OTP, como Symantec VIP para la resistencia al phishing, pero en este caso el robo físico ya no es un requisito para la explotación. En cambio, si su token se implementa en el software, cualquier intrusión en su computadora (virus, etc.) podría hacer una copia de su dispositivo de autenticación y usarla en su computadora sin su conocimiento. Entonces no es bastante tan bueno como un dispositivo físico, pero es mucho menos costoso.

    
respondido por el tylerl 23.10.2017 - 04:45
fuente
0
  

¿Cómo se comparan las aplicaciones con [...] el uso de un token de autenticación de hardware?

A primera vista, no difieren demasiado. Bueno, en ambos casos tiene otro dispositivo que realiza un paso de verificación criptográfica adicional para usted. Pero una diferencia importante es la complejidad del sistema (todo el software en ese dispositivo).

En un teléfono inteligente hay una gran cantidad de piezas interactivas de software de diferentes proveedores (aplicaciones), mientras que un token de autenticación dedicado es mucho más sencillo ya que sirve solo para este propósito. Por lo tanto, la probabilidad y la superficie de vulnerabilidad son generalmente más bajas para el sistema más simple.

Otra diferencia sería el algoritmo real utilizado para ese paso de autenticación. Pero esto no depende de ninguna manera del hardware. Sin embargo, las aplicaciones tienden a ser más simples, por ejemplo. Los generadores de contraseña de un solo uso basados en el tiempo, mientras que los otros suelen ser más sofisticados en cuanto a su único propósito, por ejemplo, U2F utiliza criptografía de clave pública basada en desafíos. Por cierto, esa es una de las razones por las que usar U2F también requiere soporte desde el navegador para enviar el desafío a la palanca U2F.

  

¿Qué tan real es la posibilidad de que un sistema Android sea [...] secuestrado y que se extraigan [...] claves secretas?

Bueno, es real que puedes hackear un teléfono móvil como cualquier otro sistema informático y obtener acceso a root . Si se puede extraer una clave, depende de cómo la aplicación almacena ese secreto. Pero como tiene que guardarlo y como no hay una memoria privada real en los dispositivos Android (AFAIK), un atacante que obtuvo acceso root podría copiar la clave.

  

[...] ¿hay otras ventajas para 2FA basado en aplicaciones?

En un nivel de seguridad simple, no creo que haya ninguna ventaja para los teléfonos inteligentes en comparación con el hardware dedicado. Pero las aplicaciones suelen ser mucho más fáciles de instalar y configurar que los sistemas especializados. Y un sistema que es complicado de usar por un usuario promedio, no mejora nada en el mundo real. También tenga en cuenta que esos sistemas especiales generalmente necesitan soporte adicional del proveedor de servicios, y si una técnica es complicada de implementar o casi no se usa, el mejor usuario no puede hacer nada sin los servicios compatibles.

  

Dado que [...] autentica una solicitud o sesión de inicio de sesión en tiempo real, ¿no es vulnerable a los ataques de phishing de reproducción en tiempo real?

Por lo que puedo ver, generalmente puedes hacer un ataque Man-in-the-middle y secuestrar la sesión autenticada. Pero eso es lo que pretenden evitar los certificados SSL. Y se acompaña de un cifrado que limita la facilidad de uso de los ataques de repetición simples. Una parte de SSL, la reproducción en tokens basados en tiempo es una posibilidad. Sin embargo, un proveedor de servicios podría alistar los tokens utilizados con éxito y evitar las repeticiones. Aun así, si el atacante fuera lo suficientemente rápido, él sería quien tuviera éxito.

    
respondido por el Cryptjar 22.10.2017 - 23:55
fuente

Lea otras preguntas en las etiquetas