Uso de la contraseña, entre otros valores, como datos clave en la autenticación de dos factores

3

Estoy escribiendo una implementación y una tesis sobre la autenticación de dos factores, y actualmente estoy investigando. Actualmente estoy buscando una implementación para generar de manera determinista una clave compartida compuesta basada en ciertos datos, que usaré para TOTP. M'Raihi, et al. Especifican en RFC 4226 (capítulo 8, Secretos compartidos compuestos, página 14) que un compuesto clave compartida:

  

"[...] puede consistir en cualquier dato conocido en el token pero no fácilmente   obtenido por otros ".

Especifican los siguientes ejemplos:

  
  • PIN o contraseña obtenidos como entrada del usuario en el token
  •   
  • número de teléfono
  •   
  • Cualquier identificador único programáticamente disponible en el token
  •   

Para mí, esta me pareció una forma razonable de generar una clave compuesta compartida (con algunas desventajas que están fuera del alcance de mi pregunta). RFC 4226 parece un documento sólido y de alta calidad de una fuente confiable con escritores que tienen artículos sobre múltiples temas avanzados. Para mí, parece que se puede confiar en que los escritores y el documento se utilicen para una implementación segura.

Luego me encontré con " El caso de la autenticación móvil de dos factores "(desafortunadamente requiere inicio de sesión / pago, pero tengo acceso gratuito a la misma usando mi cuenta de la universidad) por Dimitri DeFigueiredo, quien es investigador de criptografía y seguridad en Adobe.

El documento es más un caso, ya que el título revela, un caso para la autenticación móvil de dos factores. Sin embargo, él hace un par de reclamos que me interesaron. Es decir, lo siguiente, que para mí parece contradecir RFC 4226 (énfasis mío):

  

"Por sí solo, un token robado en el teléfono no debería proporcionar una manera de autenticar a un atacante y no puede filtrar el PIN correspondiente ".

Esto me hizo preguntarme si usar una contraseña en una clave es realmente una buena idea. Mi pregunta principal es si el uso de la contraseña en la clave compartida compuesta puede filtrar información sobre cómo se genera la clave compartida. O peor, ¿comprometer completamente la seguridad de la clave? Sé que este tipo de recuentos es una segunda pregunta, pero: ¿los datos que se usan para la clave deben ser salados / salpicados / con hash o esto también compromete la seguridad?

Como una pequeña nota: no creo que vaya a utilizar el documento de DeFigueiredo. Parece estar mezclando PIN's para desbloquear teléfonos con autenticación de dos factores y algunas otras declaraciones vagas que me hacen dudar de la calidad del documento. Por otro lado, tiene un trabajo en Adobe como investigador de criptografía, por lo que podría no estar obteniendo lo que dice. Cualquier comentario sobre la calidad de ese documento sería muy apreciado, si alguien tiene la oportunidad de leerlo.

    
pregunta Bono 05.11.2015 - 17:15
fuente

1 respuesta

2

La parte importante de esto parece ser la siguiente línea en el RFC:

  

En este escenario, el secreto compartido K compartido se construye durante   El proceso de aprovisionamiento de un valor semilla aleatorio combinado con uno   o más factores de autenticación adicionales.

Los datos clave nunca deben ser solo los datos conocidos en ese punto, sino que deben derivarse de ellos mediante un proceso sólido, que garantice que los componentes individuales de una clave compuesta estén lo suficientemente mezclados para hacer la reconstrucción imposible.

Esto no necesariamente contradice la declaración DeFigueiredo: si usó un PIN de 1234 y sus tokens eran 1234-token1 y 1234-token2, claramente los tokens pierden el PIN. Si eran MTIzNC10b2tlbjE= y MTIzNC10b2tlbjI= , todavía lo filtran, solo un poco menos obvio: estas son solo las representaciones de base-64 de los tokens anteriores. Si fueron 32e38e71a26e560092e395a02fb85132 y bd7c0c61696eb5716fc866c21246e846 , se necesita mucho más esfuerzo para averiguar qué está sucediendo, en este caso, la representación hexadecimal del hash MD2 de las cadenas anteriores. No es un proceso de generación sólido, pero muestra el principio básico.

Por lo tanto, si tiene un proceso de generación sólido, puede poner casi todo lo que quiera en él, y no filtrar lo que sucedió.

    
respondido por el Matthew 05.11.2015 - 17:40
fuente