¿Debo almacenar remotamente mi sal? [duplicar]

9

Cuando los usuarios se registran en mi sitio, quiero almacenar su nombre de usuario y contraseña de hash en mi base de datos. Cuando tenga esa contraseña, la añadiré usando PHP.

El problema es que no quiero almacenar la sal en una base de datos que pueda verse comprometida, lo que anula el propósito de la salazón, ¿no?

En su lugar, quiero tener una sal única por usuario que se almacena en un servidor separado, por ejemplo, ¿una plataforma en la nube?

¿Es seguro / es el camino correcto?

    
pregunta Prinsig 22.10.2014 - 18:27
fuente

5 respuestas

28

No es un problema si el atacante aprende las sales. Las sales no están destinadas a ser secretas. Lo que es importante para un salt es que es único para cada instancia de contraseña con hash (es decir, no solo un salt único por usuario, sino que el salt del usuario debe cambiarse cuando el usuario cambia su contraseña).

Si piensa que su sal es algo que puede compartirse entre contraseñas, pero el atacante no debe saberlo, entonces eso no es una sal; esa es una clave . Algunas personas llaman a estas claves "pimienta" en el caso de la aplicación de contraseñas. Este es un concepto bastante distinto de las sales y, en general, agrega complejidad y aumenta la frecuencia de falla sin mejorar realmente la seguridad. Obtenga los conceptos básicos primero (es decir, utilice la función correcta con las sales adecuadas).

El método normal es almacenar la sal junto con el valor de hash. Preferiblemente, permite que la biblioteca de hashing de contraseñas genere el salt y maneje la codificación del valor de sal y hash como una sola cadena. Así que asegúrate de usar PHP 5.5 (o más nuevo) y de password_hash () (y no use la configuración manual de sal; la biblioteca hace lo correcto de manera predeterminada, así que deje que lo haga). Entre las posibles funciones de hashing de contraseñas , bcrypt es lo mejor para ti puede tener ahora, y eso es lo que password_hash() usará.

    
respondido por el Tom Leek 22.10.2014 - 18:55
fuente
5

Mi respuesta va a diferir de todos los demás. Tom Leek y Xander brindaron una buena perspectiva, por lo que aquí va mi respuesta a tu pregunta inicial, ampliando este comentario tuyo:

  

" No quiero almacenar la sal en una base de datos que podría estar   comprometido: eso anula el propósito de la salazón, ¿no? "

Sí, y no. Si alguien comprometió su base de datos, tiene cosas más importantes de las que preocuparse. El mero hecho de llegar tan lejos abre el potencial para olfatear el cable, donde si no se usa el cifrado, los datos son visibles antes de ser cifrados y metidos en una base de datos.

Las sales protegen porque agregan una capa para contrarrestar el agrietamiento. Un cracker necesita un hash de contraseña y un salt para producir algo que se pueda comparar con un hash conocido para encontrar la contraseña correcta. La mayoría de los cambios de salazón, de lo contrario, si esto ocurriera, la salada sería inútil:

User1 (password) [ kitten + your_static_salt = thundercat ]
User2 (password) [ kitten + your_static_salt = thundercat ]

En las obras teatrales anteriores, dos usuarios han elegido la palabra "gatito" como su contraseña que se utiliza para producir el resultado de "thundercat". Si esto es cierto, la porción de salazón es algo inútil. Si está utilizando password_hash de PHP, el salt se genera aleatoriamente para usted, el resultado sería el siguiente (por supuesto, minimizado para mayor claridad):

User1 (password) [ kitten + password_hash = thundercat ]
User2 (password) [ kitten + password_hash = uppercut ]

En lo anterior, vemos la misma contraseña, el password_hash de PHP cambia la sal cada vez. No hay necesidad de reinventar las ruedas aquí, ya que tendrías que hacer algunas inmersiones profundas en crypt () para entenderlo. Si usted es realmente interesado en el uso de sal y la seguridad de las contraseñas, eche un vistazo a phpass del Diseñador Solar Sin embargo, cuando dices que te preocupa que alguien haya comprometido la propia db, esto cambia el alcance de lo que podría hacer un atacante sin siquiera tener que descifrar las contraseñas.

    
respondido por el munkeyoto 22.10.2014 - 19:33
fuente
4

Agregaría complejidad sin agregar mucho valor.

No anula el propósito de la salazón, como haces, porque una sal no tiene la intención de ser secreta, sino única. El objetivo no es hacer que sea imposible descifrar la contraseña del hash, sino hacer que no sea posible calcular previamente los hashes que pueden compararse directamente con los suyos para ver si hay alguna coincidencia y para garantizar que las contraseñas idénticas resulten en diferentes hashes.

Por lo tanto, tratar de mantener la sal por separado y en secreto no es parte del diseño de la construcción, y sería mejor utilizar el tiempo y los recursos de desarrollo para fortalecer y proteger su aplicación y base de datos de riesgos en primer lugar .

    
respondido por el Xander 22.10.2014 - 18:36
fuente
3

No es necesario.

Piénsalo de esta manera ...

Si su servidor tiene acceso a las sales y un atacante obtiene la raíz de su servidor, él también tendrá acceso a sus "sales almacenadas remotamente" donde sea que se encuentren.

Ya que estás usando PHP, revisa las funciones password_hash y password_verify.

    
respondido por el darkAsPitch 22.10.2014 - 18:31
fuente
2

No, no hagas eso.

Primero: las sales no son secretas. Se utilizan para asegurarse de que invertir el hash para una contraseña no revela todas las copias de esa contraseña en su base de datos. Se utiliza para hacer más difícil revertir el hash.

Segundo: aumentará la latencia. Su sistema de autenticación tendrá que obtener el nombre de usuario y la contraseña del usuario, acceder a una base de datos, obtener el ID de usuario, pedirle a un servidor remoto un salt para ese ID de usuario, calcular y decidir si el usuario tiene la contraseña correcta o no.

Tercero: su script tendrá las credenciales para acceder a la base de datos de sal . Si alguien ingresa a su sistema, también podrá acceder a esa base de datos. Incluso si no pueden acceder a la base de datos directamente, tendrán acceso a la base de datos de ID de usuario , recorrerán todos los ID de usuario y obtendrán todos los datos de la base de datos de sal.

Y todas estas desventajas no te darán ninguna seguridad adicional, ni siquiera será un poco mejor.

La criptografía es un problema resuelto. Muchos y muchos criptógrafos expertos ya han definido la mejor manera de cifrar y cifrar la información. Simplemente siga las pautas y estará seguro.

    
respondido por el ThoriumBR 22.10.2014 - 19:09
fuente

Lea otras preguntas en las etiquetas