salted - hash with salt java

Salting Your Password: Best Practices? (8)

Siempre he tenido curiosidad ... ¿Qué es mejor al salar una contraseña para hash: prefix o postfix? ¿Por qué? ¿O importa, siempre y cuando sal?

Para explicar: todos (afortunadamente) sabemos ahora que deberíamos salt una contraseña antes de almacenarla en la base de datos [ Editar: para evitar cosas como lo que le sucedió a Jeff Atwood recientemente ]. Por lo general, esto se hace concatenando la sal con la contraseña antes de pasarla a través del algoritmo hash. Pero los ejemplos varían ... Algunos ejemplos anteponen la sal antes de la contraseña. Algunos ejemplos agregan la sal después de la contraseña. Incluso he visto algunos que intentan poner la sal en el medio.

Entonces, ¿cuál es el mejor método y por qué? ¿Hay algún método que disminuya la probabilidad de una colisión hash? Mi Google no ha arrojado un análisis decente sobre el tema.

Editar: ¡ Grandes respuestas, amigos! Lo siento, solo pude elegir una respuesta. :)

Creo que todo es semántica. Ponerlo antes o después no importa, excepto en un modelo de amenaza muy específico.

El hecho de que está allí se supone que debe derrotar a las tablas del arcoíris.

El modelo de amenaza al que aludí sería el escenario en el que el adversario puede tener tablas arcoiris de sales comunes añadidas / antepuestas a la contraseña. (Diga la NSA) Supongo que lo anexaron o anexaron pero no a ambos. Eso es una tontería, y es una pobre suposición.

Sería mejor suponer que tienen la capacidad de almacenar estas tablas de arco iris, pero no, por ejemplo, tablas con sales extrañas intercaladas en el medio de la contraseña. En ese caso tan estrecho, conjeturaría que intercalar sería lo mejor.

Como dije. Es semántica. Elija una sal diferente por contraseña, una sal larga e incluya caracteres impares como símbolos y códigos ASCII: © ¤ ¡

El prefijo o sufijo es irrelevante, solo se trata de agregar algo de entropía y longitud a la contraseña.

Deberías considerar esas tres cosas:

La sal debe ser diferente para cada contraseña que almacene. (Este es un malentendido bastante común).
Use un generador de números aleatorios criptográficamente seguro.
Elija una sal lo suficientemente larga. Piensa en el problema del cumpleaños.

Hay una excelente respuesta de Dave Sherohman a otra pregunta sobre por qué debería usar sales generadas aleatoriamente en lugar de un nombre de usuario (u otros datos personales). Si sigues esas sugerencias, realmente no importa dónde pongas tu sal.

En primer lugar, el término "tabla de arcoíris" se usa indebidamente. Una tabla "arcoiris" es solo un tipo particular de tabla de búsqueda, una que permite un tipo particular de compresión de datos en las teclas. Al intercambiar el cálculo por espacio, una tabla de búsqueda que tomaría 1000 TB se puede comprimir miles de veces para que pueda almacenarse en una unidad de disco más pequeña.

Debería preocuparse por el hash para las tablas de búsqueda de contraseñas, el arcoíris u otros.

@ onebyone.livejournal.com:

El atacante tiene "tablas de arcoiris" que no consisten en los hashes de las palabras del diccionario, sino en el estado del cálculo del hash justo antes de finalizar el cálculo del hash.
Entonces podría ser más económico aplicar una fuerza bruta a la entrada de un archivo de contraseñas con sal de prefijo que sal de prefijo: para cada palabra de diccionario, a su vez cargaría el estado, agregaría los bytes de sal en el hash y luego lo finalizaría. Con la sal prefijada no habría nada en común entre los cálculos para cada palabra del diccionario.

Para una función de hash simple que escanea linealmente a través de la cadena de entrada, como un generador congruente lineal simple, este es un ataque práctico. Pero una función hash criptográficamente segura está diseñada deliberadamente para tener varias rondas, cada una de las cuales utiliza todos los bits de la cadena de entrada, por lo que calcular el estado interno justo antes de agregar la sal no es significativo después de la primera ronda. Por ejemplo, SHA-1 tiene 80 rondas.

Además, los algoritmos hash de contraseñas como PBKDF componen su función hash varias veces (se recomienda iterar PBKDF-2 un mínimo de 1000 veces, cada iteración aplicando SHA-1 dos veces) haciendo que este ataque sea doblemente impráctico.

Insertar la sal en una cantidad arbitraria de caracteres en la contraseña es el caso menos esperado y, por lo tanto, el más "seguro" socialmente, pero en realidad no es muy significativo en el caso general, siempre y cuando uses long, unique-per-password cadenas de sales.

La respuesta real, que nadie parece haber tocado, es que ambas están equivocadas . Si está implementando su propia criptografía, no importa cuán trivial sea la parte que crea que está haciendo, va a cometer errores.

HMAC es un mejor enfoque, pero incluso si está utilizando algo como SHA-1, ya ha elegido un algoritmo que no es adecuado para el uso de contraseñas debido a su diseño de velocidad. Use algo como bcrypt o posiblemente scrypt y scrypt el problema de sus manos.

Ah, y ni siquiera piense en comparar los valores hash resultantes para la igualdad con su lenguaje de programación o utilidades de comparación de cadenas de bases de datos. Aquellos comparan carácter por carácter y cortocircuito como false si un personaje es diferente. Entonces, los atacantes pueden usar métodos estadísticos para tratar de determinar qué es el hash, un personaje a la vez.

No debería hacer ninguna diferencia. El hash no será más fácil de adivinar donde sea que pongas la sal. Las colisiones hash son raras e impredecibles, en virtud de ser intencionalmente no lineales. Si hacía una diferencia en la seguridad, eso sugeriría un problema con el hash, no con el salazón.

Si usa un hash criptográficamente seguro, no debería importar si pre o postfix; un punto de hash es que un cambio de bit único en los datos de origen (sin importar dónde) debería producir un hash diferente.

Sin embargo, lo importante es usar sales largas, generarlas con un PRNG criptográfico adecuado y tener sales por usuario. Almacenar las sales por usuario en su base de datos no es un problema de seguridad, usando un hash de todo el sitio.

BCrypt hash si la plataforma tiene un proveedor. Me encanta cómo no te preocupas por crear las sales y puedes hacerlas aún más fuertes si quieres.