Mejores prácticas para la seguridad de datos en una aplicación web

5

Leí un par de artículos sobre privacidad / seguridad, pero aún no puedo obtener una idea clara de las mejores prácticas para garantizar que un atacante no pueda acceder a la información privada de los usuarios.

Para almacenar contraseñas u otros datos que se verificarán solo para verificar la autenticidad, entiendo que los algoritmos de hash como SHA-256 son candidatos perfectos, ya que la contraseña en sí no necesita ser almacenada (ni siquiera conocida) en el servidor. lado.

Sin embargo, en mi caso, además de la contraseña, les permito a los usuarios almacenar otros secretos que el servidor debe poder descifrar para el trabajo en segundo plano que leerá estos secretos para proporcionar estadísticas históricas, sin que el usuario inicie sesión Estos "secretos" suelen ser claves API para servicios externos, que podrían ser peligrosos si están en las manos equivocadas.

Una posible solución hubiera sido utilizar la sesión de usuario o las cookies para almacenar los secretos, pero además de estar sujetos a cookies o secuestros de sesión, requiere que el usuario inicie sesión para trabajar, y en mi caso necesito el servidor para poder descifrar y usar los secretos para tareas en segundo plano sin que el usuario haya iniciado sesión.

Otra solución sería cifrar los secretos en la base de datos utilizando, por ejemplo, AES-256 y manteniendo la frase de cifrado fuera de la base de datos. Si el atacante obtiene acceso a la base de datos, no podrá descifrar los secretos del usuario. Si el atacante obtiene acceso al sistema de archivos del servidor, obtiene acceso a la frase de contraseña, pero no a la base de datos ... oh, espere un minuto, ¿por qué no la base de datos? Si el atacante obtiene acceso al sistema de archivos del servidor, incluida la configuración, también obtiene acceso a la base de datos, ya que las cadenas de conexión también se encuentran en la configuración del sistema de archivos. Entonces, si el atacante obtiene acceso al sistema de archivos, obtiene acceso a la frase de contraseña Y a la base de datos ...

No puedo pensar en ninguna solución para separar realmente la frase de contraseña de la base de datos. ¿Me estoy perdiendo de algo? ¿Existe alguna solución real para proteger los secretos del usuario, de modo que al menos 2 sistemas diferentes (DB / archivos) deban ser pirateados para obtener acceso a los secretos, sabiendo que el servidor debe poder cifrar / descifrar los secretos sin la ayuda de los usuarios? / p>

Mi proyecto se ejecutará en la nube con nodejs como servidor web y mongodb como base de datos y, antes de abrirlo al público, me gustaría asegurar que sea casi imposible que un atacante recupere los secretos de los usuarios, lo cual no es así. t parece ser el caso.

Editar: En lugar de almacenar la frase de contraseña en la configuración, podría pasarla al comando al iniciar el servidor web (nodejs en mi caso). Entonces, en lugar de leer la frase de contraseña del archivo de configuración plano, la lee desde la línea de comandos. Hacer eso aseguraría que la frase de contraseña nunca se escriba en un archivo (asumiendo que puedo deshabilitar el historial de bash) y que esté solo en la memoria, lo que es más difícil de hackear, ¿no es así? El único inconveniente es que necesito iniciar manualmente el servidor si se desactiva, ya que el inicio se iniciará automáticamente sin saber la contraseña (por lo que debo iniciarlo yo mismo). ¿Pero funcionaría? ¿Es esa una práctica conocida y usada?

    
pregunta Thomas 28.01.2014 - 23:11
fuente

1 respuesta

1

Tienes razón en que no hay una gran solución.

Sí, a veces se usa el ingreso a través de CLI y el almacenamiento en la memoria RAM, pero no es demasiado difícil descargar el ram. Hay módulos de seguridad de hardware que se especializan en este escenario (investigue este término si este problema es lo suficientemente importante).

En términos generales, es mejor almacenarlo en una carpeta que tenga sus permisos muy restringidos, luego concentrarse en fortalecer el servidor para que el atacante tenga que hacer dos cosas difíciles (explotar un servicio y luego aumentar los privilegios). No lo almacene en la base de datos o en un directorio accesible para el usuario web.

Encriptarlo usando AES sería bueno. Si el atacante puede controlar el texto sin formato u observar el texto cifrado en cualquier escenario, querrá tomar muchas precauciones para asegurarse de que se implementa correctamente.

    
respondido por el Alex Lauerman 29.01.2014 - 04:05
fuente

Lea otras preguntas en las etiquetas