security - ¿Cuál es la mejor manera posible de salar y almacenar sal?
encryption cryptography (2)
Hola chicos, he leído sobre el salado 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?
Almacenar la sal sin encriptar en la base de datos al lado de 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 tablas de arcoiris cuando un atacante tiene en sus manos la base de datos.
Vea esta excelente publicación sobre el tema de Thomas Ptacek.
edit @ZJR : incluso si las sales fueran completamente públicas, aún vencerían el beneficio de las tablas rainbow. Cuando tiene datos de sal y hash, lo mejor que puede hacer para revertirlo es la fuerza bruta (siempre que la función hash sea criptográficamente segura)
edit @ n10i : Consulte el artículo de Wikipedia para obtener una función hash segura . En cuanto al tamaño de la sal, la popular implementación de bcrypt .gensalt () usa 128 bit.
Tómese un momento para leer esta muy buena descripción de sales y hashing