Colocación de sal antes del hash de una vía

Question

Colocación de sal antes del hash de una vía

#1 de Tom Leek (9 votos)
#2 de mr.spuratic (3 votos)

7

En el hashing unidireccional es común anteponer o añadir la sal al secreto y luego al hash: (sal + secreto) o (secreto + sal). Estaba pensando en esta metáfora como la sal que cae sobre un plato de comida. Por supuesto, no todo se cae al principio o al final de la placa.

¿Hay algún beneficio de seguridad si, en cambio, tuviera que distribuir aleatoriamente la sal dentro del secreto como se muestra a continuación?

Ejemplo simple donde la sal se distribuye cada otra letra:


Salt = lk2jn35  
Secret = hello  
Salted = lhke2ljlno35

Estoy seguro de que también podría encontrar una variable de "máscara" que describa la distribución de la sal en el secreto y la distribución de la sal en sí misma podría ser aleatoria de esta manera:


Salt = lk2jn35  
Secret = hello  
SaltMask = 010011101011  
Salted = hlelk2jlno35

La pregunta, sin embargo, ¿tiene esto algún beneficio de seguridad adicional más allá del método tradicional de anexos o anexos ?

hash salt cryptography

pregunta TugboatCaptain 13.08.2013 - 10:11

fuente

2 respuestas

Lea otras preguntas en las etiquetas hash salt cryptography

¿Qué significa el correo electrónico “Cambiar su contraseña en cualquier otro lugar” del servicio comprometido? Cambio de contraseña de BitLocker

score 9 · Answer 1

La combinación de la sal y la contraseña no tiene ninguna importancia SI la función hash es "perfecta" (es decir, es un oráculo aleatorio ). Sin embargo, las funciones hash perfectas no existen realmente; ni siquiera sabemos si pueden existir funciones hash "ligeramente imperfectas" (funciones que no son oráculos aleatorios pero que, sin embargo, garantizan ser resistentes a la preimagen). Las funciones hash prácticas tienen "peculiaridades" que se relacionan con su estructura interna, y deben evitarse cuidando cómo se prepara la entrada. Es extremadamente difícil saber qué forma de combinar contraseña y sal es mejor, por lo que la forma normal es dejarlo en manos de criptógrafos entrenados. Después de décadas de trabajo, estas personas han surgido con algunas construcciones que parecen ser sólidas, y es improbable que un desarrollador solitario pueda encontrar algo significativamente mejor mediante la combinación de una o dos funciones.

En cualquier caso, incluso si su método para mezclar la contraseña y la sal es bueno ( puede ser bueno, pero es difícil saberlo con seguridad), su función aún es demasiado rápida . Debes tener miles o incluso millones de invocaciones de funciones hash anidadas aquí, porque una función de hashing de contraseña debería ser inherentemente lenta . Consulte esta respuesta para un tratamiento completo de la pregunta.

score 3 · Answer 2

Consulte ¿Por qué siempre es 'HASH'? (Salt + contraseña) 'que recomendamos? . Si está buscando un método seguro de verificación de contraseña, hay mejores opciones, como señala Thomas Pornin en su respuesta a esa pregunta, y Tom Leek señala arriba.

El método H(salt|secret) puede ser susceptible a ataques de extensión de longitud aunque puedo ' No veo ninguna forma de que pueda ser útil en este contexto (ya que uno debe conocer ambos componentes para realizar este tipo de ataque, no hay ningún beneficio), no hay razón para descartarlo de inmediato.

Suponiendo que el algoritmo hash elegido sea adecuado para el propósito , sugiero las siguientes consideraciones:

El propósito de la sal no es "mejorar" el hash, es hacer que sea costoso realizar ciertos ataques precomputados
La concatenación de la sal es una operación trivial computacionalmente, y no es tan efectiva como la adecuada estiramiento de las teclas en términos de gastos . Mezclar bits alrededor de un puñado de veces es una operación trivial comparable.
Dada la intención de una sal como se usa aquí, una cosa que puede decir es que una sal más larga y aleatoria es mejor en su propósito. De ello se deduce que no hace que la sal sea más efectiva (o menos) si simplemente barajas bits de entrada.

Suponiendo que "mejor seguridad" es equivalente a "más difícil para un atacante", no hay ningún beneficio porque el el atacante conoce el sistema y el desafío no es más complejo que antes. El secreto sigue siendo el mismo secreto, y la cantidad de trabajo para recuperarlo prácticamente no cambia.

(Y, como siempre, existe el riesgo de que haya pasado por alto algún aspecto sutil del sistema, o simplemente no tenga suerte hoy, y que haya de alguna manera administrado para empeorar la seguridad general.)