¿cuál es la mejor manera posible de salar y almacenar sal?

Question

Hola chicos que he leído sobre la salazón de contraseñas, pero esto puede sonar un poco extraño. Pero, ¿cómo almaceno y aseguro la sal? Por ejemplo, en una arquitectura de neumáticos múltiples, digamos que utilizo el GUID de la máquina cliente para generar mi sal, luego el usuario queda restringido a una sola máquina, pero si uso sal aleatoria, debe almacenarse en algún lugar. Hace unos días vi una aplicación de muestra donde el hash y la sal se generaban en el sistema cliente siempre que se creaba un nuevo usuario y luego la contraseña salada y el hash se transmiten al servidor donde se almacenan en el servidor SQL. Pero si sigo este método y la base de datos se ve comprometida, las contraseñas y los valores de sal para cada contraseña estarán disponibles para la persona X. Entonces, ¿debería saltear/encriptar las contraseñas y recibir sal en el servidor? ¿Cuál es la mejor práctica de salazón?

Answer 1

Almacenar la sal sin cifrar en la base de datos junto a las contraseñas hash no es un problema.

El propósito de la sal no es ser secreto. Su objetivo es ser diferente para cada hash (es decir, aleatorio) y lo suficientemente largo como para vencer el uso de rainbow tables cuando un atacante tiene en sus manos la base de datos.

Consulte esto excellent post sobre el tema por Thomas Ptacek.

edit @ZJR: incluso si las sales fuesen completamente públicas, seguirían derrotando el beneficio de las tablas rainbow. Cuando usted tiene una sal y HASHED de datos, lo mejor que puede hacer para revertir es la fuerza bruta (siempre que la función hash es criptográficamente seguro)

edit @ n10i: Véase el artículo de Wikipedia para secure hash function. En cuanto al tamaño de la sal, la popular implementación de bcrypt .gensalt() usa 128 bit.

Answer 2

Por favor tome un momento para leer esta descripción muy buena de sales y hash

Salt Generation and open source software