fuerza de cifrado con sal "débil"

En general, no se recomienda reutilizar la contraseña como parte de la sal. La contraseña es secreta y la información puede filtrarse de esa manera, dependiendo de los detalles internos de la función hash. Te sugiero que te abstengas de ello.

El nombre de usuario es, en sí mismo, una sal no muy buena, pero si solo tienes eso, entonces úsalo. La única propiedad de las sales es singularidad . Cuando usa el nombre de usuario como sal, corre el riesgo de colisiones de sal cuando:

• El mismo nombre de usuario se usa en dos sistemas distintos (por ejemplo, si cada instancia del sistema tiene un usuario "admin" con ese nombre de usuario exacto, vale la pena que los atacantes calculen las tablas del arco iris utilizando "admin" como salt).

• Un usuario cambia su contraseña (la contraseña antigua y la nueva usan el mismo salt, y un atacante puede atacar ambos en paralelo).

Si sus nombres de usuario son únicos en todo el mundo (por ejemplo, direcciones de correo electrónico), se evita el primer problema. Una variante es usar como sal el nombre de usuario con, como sufijo, un signo '@' seguido del nombre del servidor. Para los cambios de contraseña, puede disminuir la intensidad del problema por el simple recurso de no requerir cambios regulares de la contraseña de sus usuarios (de todas formas, esto no mejora la seguridad).

A pesar de su reclamo de no tener ningún medio para almacenar una sal, sí (posiblemente sin darse cuenta): obviamente está almacenando el nombre de usuario y el hash de la contraseña de cada usuario. El mismo almacenamiento se podría usar para almacenar un elemento más para cada usuario, un sal aleatorio por usuario.

Tampoco necesita información adicional sobre el usuario para generar un salt. Solo necesita un generador de números aleatorios una vez, cuando se crea la cuenta de usuario. Por lo tanto, solo necesita una buena fuente de entropía, que, por supuesto, es más fácil decirlo que hacerlo en un servidor sin cabeza.

Tal vez la confusión se deba al hecho de que el término "sal" se usa a veces con diferentes significados. Algunos autores parecen usar el término "sal" para una entrada adicional global (constante) utilizada para calcular los hashes de contraseña. Aunque es lo suficientemente bueno como para frustrar algunos ataques de arco iris, no es una buena manera de implementar una sal. Una mejor manera es elegir una sal diferente para cada usuario. Muchas implementaciones, por ej. función de cifrado de PHP , incluso agregue el salt (y algunos parámetros de hashing) al valor de hash calculado para conveniencia, lo que le libera de tener que almacenar y recuperar el sal por separado.

A algunos programadores les disgusta almacenar el salt en una base de datos, argumentando que el salt podría proteger en el caso de que un atacante obtenga la base de datos de contraseñas pero no un poco de sal global incluido en el código de autenticación. Sospecho que podría ser de esta persuasión en base a su comentario acerca de no tener una base de datos remota. Tenga en cuenta que este argumento puede ser peligroso: si se asume que su base de datos de contraseñas puede verse comprometida pero que alguna fuente de información externa (la sal o las sales) no lo es, entonces es mucho mejor que asegure su contraseña por usuario. base de datos, así como este almacén adicional de información por usuario. Cumplen exactamente la misma función y, por lo tanto, deberían ser igualmente fáciles (o difíciles) de asegurar.