¿Revelar los códigos de dos factores reduce la seguridad?

3

Si tuviera que mostrar públicamente el código de 6 dígitos de mi autenticador de google, ¿disminuiría la seguridad de mi cuenta más allá de su tiempo de vida válido?

¿Qué pasaría si fuera el código y la hora en que se generó?

¿Y si fueran N códigos secuenciales?

Me gustaría saber por qué o por qué no para cada caso.

    
pregunta Aaron McMillin 28.07.2016 - 21:17
fuente

3 respuestas

4

Google Authenticator utiliza el Algoritmo de contraseña de un solo uso basado en el tiempo (" TOTP "), que funciona calculando HMAC con una clave secreta sobre una marca de tiempo.

HMAC es un código de autenticación de mensaje ("MAC"). El requisito de seguridad estándar para un MAC es que sea capaz de resistir falsificación existencial (un atacante que no sepa la clave no debería poder falsificar ningún (message, tag) pares) bajo ataque de texto elegido adaptable (permitimos al atacante la capacidad de hacer que el defensor calcule las etiquetas de los mensajes que elija el atacante y aprenda de los resultados anteriores al elegir nuevas consultas).

Sin embargo, el resultado de 6 dígitos de TOTP no es una salida MAC directa, sino un truncamiento de una etiqueta MAC, por lo que podría plantearse la cuestión de si truncar la MAC también es una MAC segura. Sin embargo, cuando se usa HMAC con una buena función hash, también se cree que es una función pseudoaleatoria . Los PRF son MAC buenos automáticamente, y el truncamiento de un PRF también es un PRF, por lo que el truncamiento de HMAC también es un buen MAC.

TL; DR: No, a menos que el atacante pueda romper HMAC-SHA1 en condiciones desfavorables, lo que sería un gran revés para el mundo de criptografía en su conjunto, no solo TOTP.

    
respondido por el Luis Casillas 28.07.2016 - 21:47
fuente
5

No. Eso es todo el punto de TOTP / HOTP. Que no sea factible, dada cualquier secuencia de códigos válidos, generar códigos futuros o recrear la semilla.

La razón es que el algoritmo TOTP / HOTP, usa HMAC-SHA1 como hash, dado el "desafío" (ya sea el tiempo actual de UNIX o un contador de usos) y el secreto "semilla" como clave. La salida de hash resultante se trunca de acuerdo con una regla muy específica.

Esto significaría que, en su primer caso, sería imposible hacerlo, ya que varias claves válidas obtendrán el código "correcto" de 6 dígitos, pero resultarán ser incorrectos como códigos futuros de estas "claves válidas". "será inválido.

Para montar con éxito un ataque de fuerza bruta contra una semilla, al menos necesitarías 2 códigos de autenticación válidos, posiblemente más, e incluso en ese caso, no es factible (por ejemplo, prácticamente imposible) hacerlo.

    
respondido por el sebastian nielsen 28.07.2016 - 21:37
fuente
0

La primera definición de OTP en RFC 2289 basada en S / Key tenía incluso este requisito de diseño.

No se trataba de implementar la autenticación de dos factores, sino simplemente de proteger la contraseña o frase de contraseña. Simplemente se usó para evitar que la contraseña cruzara la red; obviamente, se asumió que la transmisión se podía descifrar o descifrar.

Como ya se dijo, es un diseño fundamental en todos los sistemas OTP (S / Key, mOTP, OATH) para no permitir la adivinación de futuras contraseñas basadas en contraseñas usadas.

Pero: con un algoritmo basado en eventos como HOTP, por supuesto, puede crear listas OTP. Si genera un valor OTP ahora y lo publica en Internet pero no lo usa para iniciar sesión, todos los demás pueden usarlo. Solo se invalida cuando este mismo valor se usa o un valor posterior se usa.

    
respondido por el cornelinux 29.07.2016 - 09:25
fuente

Lea otras preguntas en las etiquetas