PBKDF2: ¿se puede conocer la sal a partir del hash?

3

Entiendo que algunos KDFs combinan la sal con la salida, como bcrypt (formato criptográfico modular).

En PKCS5_PBKDF2_HMAC (específicamente, mirando implementación de OpenSSL ) con una sola iteración, es la ¿Sal sabrosa / atacable?

Estoy observando una implementación KDF que ejecuta una única iteración de PBKDF2-HMAC sobre algunos datos, usando la contraseña del usuario como el salt.

¿La sal está en riesgo de ser descubierta / es un uso correcto de PBKDF2?

(Los datos con hash se emiten desde el mismo KDF, pero con un recuento de iteraciones adecuado.)

  // hash 1 is not transmitted over network, and it used for symmetric encryption
  hash_1 = pbkdf2(salt=username, data=password, iterations=5000)

  // hash 2 is transmitted over network, as a password for auth 
  // is the salt vulnerable?
  hash_2 = pbkdf2(salt=password, data=hash_1, iterations=1)
    
pregunta Alex 07.12.2014 - 23:27
fuente

2 respuestas

4

EDITADO:

Mi primera respuesta instintiva fue NO UTILICE LA CONTRASEÑA COMO VALOR DE SALIDA. Y eso es casi todo lo que me ocupa.

Sin embargo; leyendo su publicación con un poco más de cuidado, no la sal no se almacena en el resultado del algoritmo pbkdf2.

Sin embargo; El propósito de la sal es que agrega entropía (aleatoriedad) a los datos de entrada antes del hashing.

La sal realmente no pretende ser "secreta".

El primer problema evidente que veo es el uso del nombre de usuario como el valor salt en la primera llamada a pbkdf2. Eso es totalmente predecible. ¿Por qué no se utiliza un valor de sal generado aleatoriamente que se almacena junto con el nombre de usuario y el hash de contraseña? (La contraseña en sí nunca debe almacenarse en ningún lugar).

De todos modos, es seguro decir que KDF no almacena ni transmite la sal porque es una entrada que se utiliza para generar un valor de salida unidireccional, matemáticamente no reversible. La sal en sí no existe en la salida.

Pero tanto los nombres de usuario como las contraseñas son opciones bastante malas para los valores de "sal" porque ninguno de los dos es suficientemente aleatorio (lo suficientemente seguro de la duplicación). Las contraseñas en particular son altamente susceptibles de duplicación en un gran conjunto de cuentas. Mucha gente termina usando las mismas contraseñas.

Pero si agrega sal generada aleatoriamente a contraseñas idénticas antes de incluirlas, los hashes resultantes serán completamente diferentes entre sí.

Por otra parte, tener valores de sal idénticos (predecibles) en varias cuentas o múltiples flujos de datos es una mala noticia porque introduce un grado de previsibilidad y potencialmente abre la puerta a las vulnerabilidades.

EDIT # 2:

Hashes y sal ... dado que parece haber algunas preguntas y comentarios adicionales sobre este tema, la conclusión es que los algoritmos de hash criptográficos son deterministas (la misma entrada en un algoritmo de hashing criptográfico siempre produce la misma salida).

Si esto no fuera cierto, estos algoritmos no serían útiles.

El problema desde el punto de vista de la seguridad es que si no "saltan" sus datos de entrada (generalmente, las contraseñas), los hashes que almacena o transmite no son más únicos que los datos originales.

Por lo tanto, si descifras un hash (ataques de diccionario o tablas de arco iris), habrás resuelto todos los que coincidan. Esto es exactamente lo que llevó a (¿puedo identificar un gran sitio de redes sociales de negocios por nombre?) Tener algo así como 6 millones de cuentas comprometidas hace un par de años.

"Salt" era solo un acrónimo de los días en pantalla verde para entropía (aleatoriedad). Es lindo pensar en "poner sal" en tu "hachís" (poner sal en papas o papas fritas o cualquier otra cosa).

El propósito de la "sal" es aleatorizar la entrada (la contraseña). Si la sal se genera aleatoriamente, será completamente única para cada contraseña. Agregue la contraseña y, de repente, cada contraseña es única, incluso si miles de usuarios eligen la misma contraseña.

El valor de la sal en sí no suele ser un secreto. A menudo se almacena junto con el valor de hash (o incluso se le anexa), y el secreto de datos original (la contraseña) nunca se almacena.

Entonces, cuando el usuario proporciona el secreto, la sal se agrega a la cadena provista de la misma manera que cuando se creó originalmente el hash, se introdujo en el algoritmo de hash, y si el resultado coincide con el hash almacenado, usted sabe que el usuario lo proporcionó la contraseña correcta.

Lo que dice @Fleche acerca de que los nombres de usuario no son únicos a nivel mundial es cierto, y las contraseñas ni siquiera son muy únicas en dominios pequeños, y mucho menos en todo el mundo.

Usar tanto el nombre de usuario como la contraseña como salt de esta manera podría abrirte a un ataque que realmente no habías anticipado. El nombre de usuario es predecible y no es universal único, aunque son únicos en su dominio. Pero entonces los valores de sal generalmente no son secretos de todos modos. Así que podrías estar a salvo. Pero se siente un poco superficial.

    
respondido por el Craig 08.12.2014 - 02:07
fuente
4

Una "sal" que se deriva de los datos de entrada no es sal en absoluto. En otras palabras, esta es una función hash sin sal que solo toma una contraseña y un recuento de iteraciones y calcula el hash resultante. Si el número de iteraciones es constante, la misma contraseña siempre produce el mismo hash.

El punto entero de la sal es que es la entrada adicional . Contrariamente a la creencia popular, no es secreto de ninguna manera, pero debe ser lo suficientemente aleatorio.

    
respondido por el Fleche 08.12.2014 - 01:02
fuente

Lea otras preguntas en las etiquetas