En el hashing, ¿importa qué tan aleatoria es una sal?

No. Se supone que un salt es único para que no puedas usar un ataque (como las tablas de arco iris) que calcule un hash de contraseña una vez y use ese resultado contra múltiples hashes de contraseña.

Si está interesado en hacer que sea imposible revertir el hash sin algún conocimiento secreto, agregue una contraseña específica del sitio a la contraseña proporcionada (además de la sal) antes de hashing. Una sal se almacena con el hash, por lo que no tiene sentido hacerlo difícil de adivinar.

@Honoki :
Si es un valor global o un sitio específico, entonces lo que estás pensando no es una sal, es otra cosa. Eso no quiere decir que no sea una buena idea, pero no es una sal. Normalmente, un secreto específico de la instalación se denomina "clave del sitio" o "contraseña del sitio".

Pero las sales normalmente se almacenan con el hash. Por ejemplo, aquí está la forma actual en que se almacenan las contraseñas de inicio de sesión de Unix / Linux. La contraseña aquí es "foobar":

$5$BcjmguyyH.Qrf$ADRXhi/5xb.dYU67I.JdY57uoFjel/rqMqj14QJmTQ1

• $ es el delimitador de campo
• 5 es el especificador de algoritmo hash (en este caso SHA-256)
• BcjmguyyH.Qrf es la sal (no disfrazada de ninguna manera)
• ADRXhi/5xb.dYU67I.JdY57uoFjel/rqMqj14QJmTQ1 es el hash

Dado que el objetivo de una sal es evitar que un atacante precompute hashes, diría que lo que importa es principalmente la singularidad de la sal, pero la aleatoriedad podría ser un factor para un atacante particularmente ingenioso, si sus sales son muy previsible, es concebible que un atacante pueda generar tablas de arco iris antes de un intento de intrusión para acelerar las contraseñas de craqueo una vez que obtengan los hashes.

Algunas técnicas son poco mejores que las contraseñas sin sal: usar un solo sal para toda la base de datos de contraseñas significa que solo tienen que calcular un conjunto de hashes para descifrar la base de datos completa, y usar sales que son predeciblemente derivadas de los nombres de usuario (o son los nombre de usuario real) significa que un atacante puede calcular previamente los hashes para las cuentas de usuario que están interesados en descifrar (probablemente sus cuentas de administrador, empleados privilegiados, cuentas de moderador, etc.) incluso antes de obtener una copia de la base de datos.

En resumen, las sales deben ser únicas, y deben ser impredecibles para la mejor seguridad. Los estándares criptográficos de aleatoriedad probablemente no sean necesarios, aunque son una buena manera de garantizar la imprevisibilidad.

Las sales no necesitan ser únicas. No es un requisito absoluto. Sin embargo, cuantas más sales diferentes utilices, mayor será la seguridad, por lo que si pueden ser casi únicas, eso es bueno, pero no te preocupes por que algunas personas puedan compartir una sal debido a una asignación al azar deficiente.

Salt se usa para evitar que las personas utilicen una tabla de arco iris preparada previamente para descifrar sus contraseñas. Si usa la misma sal en todas las contraseñas, ha frustrado la tabla de arco iris preparada previamente, pero puede valer la pena que los crackers creen una tabla de arco iris personalizada para sus contraseñas con sal. Si cambia la sal para algunos usuarios, entonces reduce la ganancia potencial para el cracker al producir su tabla de arco iris. Por ejemplo, si tiene dos sales usadas al azar, entonces el cracker necesita crear dos tablas de arco iris. Si usa 50 sales al azar, entonces el cracker debe crear 50 tablas arco iris para obtener más trabajo. Si utiliza una sal generada aleatoriamente para cada usuario, el cracker tiene que recrear una nueva tabla de arco iris para cada usuario. Ahora es tanto trabajo que el cracker no se molestará en intentarlo y usará un ataque diferente en su lugar.

Si ha generado sales al azar para cada usuario, existe la posibilidad de que dos o más sales de usuario sean idénticas. Esto solo afectaría marginalmente la seguridad de los sitios. Un cracker ahora podría usar una tabla arco iris personalizada para descifrar todas las contraseñas con sal idénticas. Esto podría ser un ataque viable si el número de usuarios con sales idénticas es lo suficientemente grande. Si el número de sales idénticas está en las cifras individuales, entonces no supondría un gran problema.

El valor de la sal no tiene por qué ser un secreto. Algunas personas realizan la ocultación del valor de sal, pero en general los sistemas de contraseña no lo hacen. Mantener el secreto de la sal no proporciona mucha seguridad adicional. El propósito de la sal es asegurar que los algoritmos de contraseña no sean similares para cada usuario y, por lo tanto, bloquear los ataques de la tabla arco iris. Saber que la sal no hace que los hashes sean más fáciles de romper, siempre y cuando las sales sean generalmente casi únicas.

En la mayoría de los esquemas de hashing de contraseñas, las sales deben ser globalmente únicas . Esto significa que, idealmente, cada instancia de contraseña única en todo el mundo debe tener su propio valor de sal, compartida con ninguna otra (en particular, el mismo valor de sal no debe usarse en dos servidores distintos, y la sal también debe cambiarse cuando un usuario cambia su contraseña).

La singularidad mundial y mundial es difícil, porque no hay un depósito central para las sales asignadas. Una forma fácil es confiar en aleatoriedad : si genera sus sales a partir de un generador aleatorio criptográficamente sólido (es decir, un generador "muy bueno") y si hace que sus sales sean lo suficientemente largas, entonces es probable que haya una sal. la colisión es muy baja, lo suficientemente baja como para ser descuidada. Tenga en cuenta que incluso si apuntamos a la singularidad global, la colisión ocasional no es inmediatamente fatal, por lo que podemos vivir con ese riesgo. 16 bytes es "lo suficientemente largo".

Cualquier método que garantice de manera confiable la singularidad global es bueno; pero la aleatoriedad es a menudo la que mejor escala, porque es puramente local (sin cuellos de botella en toda la red).

Mutatis mutandi , este es el mismo problema que para UUID . "UUID versión 4" en realidad 122 bits aleatorios. Tales UUID serían sales bastante apropiadas.