tradicional 2FA versus PIN + OTP

3

Acabo de migrar a una nueva empresa de correo electrónico y ofrecen un tipo de 2FA que nunca antes había encontrado.

Tradicionalmente, en 2FA ingresas username y password y luego aparece una pantalla que solicita el código generado token . A veces, simplemente agrega el token al password para veces que una segunda página no es posible, las VPN, por ejemplo, a menudo usan eso.

La nueva empresa con la que estoy tratando le hace crear un 4% PIN y cuando habilita 2FA ya no inicia sesión con su contraseña, sino que usa PIN + token ingresado en el campo de contraseña en formulario de inicio de sesión. La cuenta todavía tiene un password para acceso IMAP, SMTP, POP3, etc.

Esto me parece mucho menos seguro, pero no estoy seguro de si tengo razón. Mi idea es que una contraseña adecuadamente compleja (digamos 32 caracteres de letras, números y símbolos) seguida del token que cambia cada 30 segundos va a demorar infinitamente más tiempo que una cifra numérica de 4 dígitos PIN combinada con el mismo token .

En este caso, ¿sería más seguro usar una contraseña adecuadamente compleja sin 2FA habilitado que cambie cada par de semanas que la implementación de 2FA con PIN + token ?

Nota: La propia compañía se refiere a este sistema como 2FA y OTP de manera intercambiable, pero no estoy completamente seguro de cuál debería ser la terminología correcta.

    
pregunta jskrwyk 09.11.2017 - 11:35
fuente

3 respuestas

7

En lugar de:

  1. contraseña alfanumérica de longitud razonable (36 caracteres posibles más, digamos, una longitud máxima de 8 caracteres para un usuario típico) [no tiene en cuenta los caracteres especiales, pero ya sospecho que hay otros problemas]
  2. ficha

El sistema utiliza:

  1. contraseña de 4 dígitos (10 caracteres posibles en una longitud de 4)
  2. ficha

Esto es demostrablemente un sistema mucho más débil, incluso si diseño un sistema de contraseña muy débil (descrito anteriormente). Además, el UX es extraño, pero ese es otro factor.

Pero, ¿es demasiado débil?

El hecho de que el token cambia cada 30 s mitiga muchos problemas. Tener una contraseña significa que si alguien obtiene un generador de tokens, la cuenta todavía tiene algunas protecciones. Pero, ¿son 4 dígitos suficientes de una protección?

Dos riesgos a considerar:

  • Alguien hace fuerza bruta con el par de pin + token

Esto depende completamente de qué tan rápido el sistema permite intentos dentro de una ventana de 30 s. Por lo tanto, tal vez es lo suficientemente seguro. Pero, ¿realmente queremos confiar en un acelerador del sistema como medida de seguridad? Los aceleradores son una buena medida de respaldo, no una mitigación primaria.

  • Alguien hace fuerza bruta contra el pin si tiene el generador de fichas

Matemáticamente, pasar por todas las combinaciones tomaría 10,000 conjeturas (5000 en promedio para encontrar el éxito), si se ingresa a mano, y si asumimos pines perfectamente aleatorios. Eso es un montón de ifs. Una vez más, depende de cuántos intentos permita el sistema. Además, los pines son notoriamente fáciles de adivinar.

Compare esto con una 'contraseña compleja' (como quiera que la defina) que cambie con frecuencia. Aquí está la cosa: sin el token cambiante, cambia el tiempo a fuerza bruta de 30 a 2 semanas (en su escenario). Ahora, el factor relevante es la complejidad (o entropía) de su contraseña y su sistema para cambiarla de manera confiable con frecuencia. Nuevamente, muchas dependencias.

Como puede ver, es difícil comparar los factores que describió. Un montón de 'ifs'. Para los factores sobre los que tengo control y los riesgos que me preocupan, podría elegir el pin + token (suponiendo que el 2FA se implementa correctamente (gritos, otro 'si')).

Pero realmente, elegiría otro servicio que pueda implementar 2FA correctamente.

    
respondido por el schroeder 09.11.2017 - 12:20
fuente
1

No es necesario restringir la parte de conocimiento (primer factor) a un PIN de 4 dígitos. A menos que estén usando un producto muy malo, viejo en el backend. Creo que RSA inicialmente hizo eso. Pero bueno, ¡RSA SecurID comenzó en 1986!

Todos los demás productos hoy en día permiten un "PIN", que en realidad puede ser una contraseña.

Pero también hay otro aspecto, debe considerar:

Por supuesto, una contraseña más larga (factor único) tiene más entropía que un PIN de 4 dígitos y un código OTP de 6 u 8 dígitos. PERO: Su contraseña se almacena en una base de datos de contraseñas, que a veces ... ... bueno, se pierde. Y luego el atacante puede forzar el hash de tu contraseña.

Por supuesto, el "PIN" de una solución 2FA también está en cualquier lugar. Y también la clave secreta, que se usa para generar el valor de OTP, se almacena en otro lugar, con suerte cifrada. Pero estas suelen ser ubicaciones diferentes y diferentes métodos de hashing / encriptación que no deben ser vulnerables a la misma inyección de SQL.

Estoy involucrado en el desarrollo de una solución 2FA, que utiliza diferentes formas de almacenar esta información: enlace

Plus: Incluso podría usar el primer factor (contraseña) desde otra ubicación como un directorio LDAP. De esta manera, las formas de ataque varían mucho.

    
respondido por el cornelinux 09.11.2017 - 21:30
fuente
0

Esta es la forma en que 2FA siempre se hizo con tokens mucho antes de que llegara la "autenticación en dos pasos". La principal preocupación con dos pasos es que pierde si el nombre de usuario y la contraseña son correctos antes de que ocurra la autenticación. Hay un beneficio operativo en el método de adición de pin: funciona con cualquier front-end que admita nombre de usuario y contraseña. Muchas VPN, etc. no admiten dos pasos.

    
respondido por el nowen 09.11.2017 - 13:46
fuente

Lea otras preguntas en las etiquetas