Ya que estoy encriptando todas las contraseñas con cada una de ellas, ¿hay algún beneficio si la sal es realmente aleatoria, o un contador incremental o una guía sería lo suficientemente bueno? Además, ¿hay un beneficio de tener una sal más grande en comparación con una sal más pequeña?
EDITAR: Ya que se establece que los hashes no deben ser demasiado pequeños: ¿Cuál es el tamaño suficiente de una sal? ¿Hará un guid (16 bytes)?
El propósito único de la sal es ser único : no hay dos contraseñas con hash que usen el mismo valor de sal. Esto tiene por objeto evitar el costo compartido, como las tablas hash precalculadas.
La singularidad debe ser mundial . Por ejemplo, supongamos que usaste un contador simple como sal. En consecuencia, el valor "1" se usará como sal para la primera cuenta creada, probablemente para el administrador del servidor. Esto será cierto para todas instancias instaladas de ese servidor. Esto hace que valga la pena calcular una tabla grande (por ejemplo, una rainbow table ) de posibles contraseñas con hash que usan "1" como sal, porque esa tabla podría usarse para atacar la contraseña del administrador en todos los servidores que usan ese software. La palabra para meditar aquí es "vale la pena".
Dado que la singularidad de a nivel de servidor no es suficiente, un contador no será suficiente; el nombre de usuario tampoco es un buen salt (los nombres de usuario son únicos en un servidor determinado, pero hay muchos 'Bob', 'Joe' y 'DarkLord42' por ahí). Un UUID (GUID) debe hacer el truco. También puede usar un generador pseudoaleatorio fuerte y uniforme ( /dev/urandom , CryptGenRandom() , java.security.SecureRandom ... dependiendo de la plataforma que use) y obtener suficientes bytes aleatorios para que los riesgos de reutilizar un valor de sal sean lo suficientemente pequeños; 16 bytes son suficientes para eso. El uso de la aleatoriedad es la "forma robusta" porque produce unicidad con una probabilidad suficientemente alta, sin tener que depender de las convenciones mundiales.
Gracias al comentario de Hendrik sobre la pregunta, encontré un hilo relacionado con esto. Aquí están mis conclusiones:
Si todos (o al menos varios) usaron el mismo conjunto de sales (es decir, incrementando números o sales cortas), se podría crear una tabla de arco iris para todas las sales repetidas, haciendo que esos hashes salados sean menos seguros.
Por lo tanto, la sal también debería ser preferiblemente única en todos los sistemas y no solo dentro de mi sistema para evitar la creación y el uso de un conjunto de tablas arcoiris para comprometer varios sistemas. (Una tabla para la sal = 1, una para la sal = 2, otra para la sal = 3 y así sucesivamente.)
No se requiere que una sal sea aleatoria ni secreta. Solo está destinado a detener los ataques usando, por ejemplo, Las mesas del arco iris, o hacen que ese ataque sea mucho más lento. Si no me equivoco, debería ser seguro incluir una contraseña de usuario con su nombre de usuario.