Cifre los datos del usuario cuando inicie sesión con Facebook, Gmail, etc.

Navega tus respuestas
5

Hice un sistema de inicio de sesión . El usuario puede iniciar sesión por:

  • usando un correo electrónico / contraseña normal (cifrado).
  • utilizando un servicio como facebook, gmail, etc.

Hasta ahora todo bien. Ahora quiero almacenar información confidencial (credenciales ftp) en la base de datos de manera segura. Esto es muy fácil para los primeros usuarios: cuando el usuario inicia sesión con su correo electrónico / contraseña, la contraseña se revisa con un sal (predeterminado) para verificar la autenticación, y con otro sal para obtener un hash fuerte X.

Luego uso este hash X como contraseña para cifrar los datos confidenciales que el usuario desea almacenar. De esta manera, el acceso completo al código y la base de datos NO compromete los datos del usuario. *

¿Hay alguna manera de lograr un nivel de seguridad similar para los usuarios que inician sesión con un servicio que, inherentemente, no tienen una contraseña para empezar? Muy recomendable una molestia del lado del servidor y no agregar complejidad adicional para el usuario. Estas son todas las opciones que puedo ver con sus problemas:

  1. Requieren que cada usuario, incluso Facebook / Gmail / etc, escriba y recuerde una contraseña. Este es, de nuevo, el principio que me hizo integrar esos servicios en primer lugar.

  2. Use una contraseña de cifrado única para todo el servidor. Quiero protegerme contra el acceso completo al código y la base de datos, por lo que nadie (incluidos los desarrolladores / administradores / etc) puede acceder a estos datos privados.

  3. Usa algunos datos específicos del usuario. Esta sería la identificación del usuario de Facebook, por ejemplo. Se puede recuperar simplemente haciendo una búsqueda de su correo electrónico en fb, por lo tanto no es seguro.

pregunta Francisco Presencia 09.01.2014 - 23:13
fuente

2 respuestas

2

Está solicitando generar datos secretos desde una única fuente no secreta. No se puede hacer bajo esas condiciones exactas. Necesita una 'fuente de secreto'. Puede intentar guardar una clave en un archivo de configuración, tal vez encriptado con otra clave, o puede mover algún aspecto a una máquina diferente y segura, como usar un Módulo de seguridad de hardware (HSM) para alojar su encriptación y claves. Pero no puedes crear un secreto recreable a partir de un conjunto finito de datos y esperar que un atacante no pueda replicar tu hazaña.

    
respondido por el John Deters 10.04.2014 - 20:52
fuente
0

Su pregunta parece ser: "Quiero almacenar de forma segura las contraseñas de los usuarios, pero de manera reversible". Básicamente, esto significa que desea implementar DRM (en su servidor), que es básicamente imposible, especialmente en un escenario de biblioteca de uso común.

Necesitaría un servidor / servicio separado y desconectado para almacenar las credenciales de usuario, y ese servidor solo sería accesible a través de una API que manejaría solicitudes como:

  • "Guardar $ ftp_user_and_password para $ user_id"
  • "Cargar $ these_files a FTP para $ user_id"

El servidor tendría que estar completamente desconectado de la aplicación (y no ser accesible a otras solicitudes entrantes). Esto es similar a, por ejemplo, el manejo de tarjetas de crédito.

Además, menciona que su necesidad real es proteger las credenciales de FTP proporcionadas por el usuario.

Además de otras medidas de seguridad, sería mucho más seguro obligar a sus usuarios a crear un nuevo usuario de FTP para su servicio, usando las credenciales que genere en su servidor ("Cree una nueva cuenta de usuario de FTP con username = my_service , contraseña = long_random_string ").

Esto significa que el usuario simplemente no le dará su contraseña FTP "común" (que también es probable que use para otras cuentas) que posiblemente resulte en una gran cantidad de problemas en caso de que un tercero malicioso acceda a sus datos. simplemente puede enviar un correo electrónico a todos sus usuarios y pedirles que revoquen el acceso a su cuenta de usuario FTP específica del servicio. (Si pierde su contraseña "común", es probable que muchos usuarios (sin duda más de cero) no cambien su contraseña común (FTP) porque sería demasiado inconveniente).

Aún tendría que pensar en proteger la contraseña específica del servicio, pero en el peor de los casos sería mucho más manejable.

    
respondido por el Joel L 13.01.2014 - 15:21
fuente

Lea otras preguntas en las etiquetas

¿Se puede detener el enlace de BeEF con las políticas de seguridad de contenido? ¿Qué hacer si un proveedor no asigna un CVE para una vulnerabilidad de reconocimiento?