He leído un poco sobre el tema de Hashes and Salts y se me ocurrió una idea para un esquema de salado, pero quería consultarlo con algunas personas más instruidas que yo.
Mi idea básica es usar el hash de contraseña inicial como un salt para un segundo hash, es decir.
password = 'foobar'
final_hash = sha1( sha1( password ) + password )
Si alguien puede explicar por qué esto podría ser una mala idea, realmente lo apreciaría.
¡Gracias!
No lograrás nada. Considere dos usuarios con la misma contraseña, sal, entre otros, está diseñado para lograr diferentes hashes para la misma contraseña.
En el ejemplo:
Pero con tu algoritmo terminarás con el mismo hash:
También, no enrolle su propio .
Una sal se utiliza para:
Una sal debe ser aleatoria y suficientemente larga (por ejemplo, 128 bits aleatorios) para que su entropía sea grande porque solo una sal con una gran entropía puede evitar ataques a través de tablas de arco iris.
Por lo general, no hay ninguna razón para derivar la sal de algunos de los atributos del usuario, por ejemplo. La contraseña o nombre de usuario. Un esquema para el hashing de contraseñas que se usa comúnmente en la práctica es bcrypt. La implementación de Java de bcrypt que conozco ( see ) crea automáticamente un salt aleatorio para cada contraseña. La sal es parte del hash bcrypt para que no tenga que manejar la sal de ninguna manera especial. La implementación también proporciona métodos para comprobar las contraseñas que descomponen automáticamente el hash bcrypt en su salt y el hash de la contraseña real.
Bcrypt también ofrece un factor de carga para aumentar la complejidad requerida para calcular un hash. Esto es útil para evitar ataques de fuerza bruta porque frustra a un atacante para calcular una gran cantidad de hashes.
En conjunto, realmente no hay ninguna razón para implementar su propio esquema para el hashing de contraseñas.
Lea ¿Cómo hacer hash de las contraseñas de forma segura? , no debe rodar las suyas. @ThomasPornin tiene una gran respuesta a esa pregunta , y la sección sobre Generación de sal incluye (entre muchos más buenos consejos ) la siguiente sabiduría:
El punto principal y único de la sal es ser lo más único posible. Siempre que se reutiliza un valor de sal en cualquier lugar, esto tiene el potencial de ayudar al atacante.
Por ejemplo, si usa el nombre de usuario como sal, entonces un atacante (o varios atacantes en conflicto) podría encontrar valioso construir tablas de arco iris que ataquen la función de hashing de contraseña cuando la sal es "admin" (o "root" o "joe") porque habrá varios, posiblemente muchos sitios en todo el mundo que tendrán un usuario llamado "admin". De manera similar, cuando un usuario cambia su contraseña, generalmente mantiene su nombre, lo que lleva a la reutilización de sal. snip
La forma barata de obtener la singularidad es usar la aleatoriedad. Si genera su sal como una secuencia de bytes aleatorios del PRNG criptográficamente seguro que ofrece su sistema operativo (/ dev / urandom, CryptGenRandom () ...), obtendrá valores de sal que serán "únicos con una probabilidad suficientemente alta. ". 16 bytes son suficientes para que nunca veas una colisión de sal en tu vida, lo cual es excesivo pero lo suficientemente simple. snip
¡Esencialmente, no puede usar la contraseña para generar un salt para la contraseña, ya que la ÚNICA entrada es la contraseña!
Debería usar un generador de números aleatorios para generar sales únicas por usuario (y almacenarlas en texto sin formato en la base de datos, junto con el hash de la contraseña y el número de iteraciones o factores de trabajo utilizados [para que pueda aumentarlo fácilmente más adelante] ), y el consejo general aquí es para una sal aleatoria de aproximadamente 16 bytes. 8 bytes es probablemente un mínimo práctico para la longitud de la sal.
Lea otras preguntas en las etiquetas password-policy hash salt