Almacenar la información de autenticación de terceros de forma segura

8

Supongamos que hay una aplicación web multiusuario que requiere acceso al buzón del usuario (en un servicio de terceros, como gmail, etc.). Este acceso debe ser persistente. Lo que significa que tendríamos que almacenar la contraseña de usuario. Lo que crea un punto de vulnerabilidad: si alguien tiene acceso a dicho sistema, podría robar toneladas de los buzones de los usuarios. ¿Hay alguna manera de reducir el riesgo en tal configuración? P.ej. para algunos sitios web, OAuth podría reducir el riesgo ya que los tokens necesitan claves de consumidor, pueden ser restringidos y pueden caducar fácilmente si ocurre algo malo. Pero todo esto no está disponible para servidores de correo. Entonces, ¿alguna sugerencia sobre una buena manera (si existe) de almacenar dicha información de una manera más segura?

    
pregunta StasM 24.12.2010 - 09:26
fuente

2 respuestas

6

La experiencia muestra que si un sitio como este se encuentra en la Internet pública y se vuelve lo suficientemente popular, se convierte en un gran objetivo y tiene una alta probabilidad de un compromiso desastroso. Tenga en cuenta bien las respuestas en esta extensa discusión (sobre un objetivo algo diferente):

Si elige seguir adelante, asegúrese de advertir a sus usuarios sobre los riesgos muy reales. La defensa en profundidad es obligatoria: mantenga la máquina de almacenamiento de contraseñas real fuera de la web, accedida a través del firewall con una interfaz muy simple, construida en la plataforma más segura que pueda encontrar, con mucho fortalecimiento y monitoreo, una buena IDS, etc. etc.

    
respondido por el nealmcb 24.12.2010 - 20:42
fuente
2

Como usted dice, este es un punto débil potencial. Pero la forma de arreglarlo tiene mucho que ver con la forma en que se implementa la aplicación. p.ej. si se ejecuta como una aplicación java en un contenedor, es posible escribir el token en el montón de la aplicación después de que se haya iniciado. Desde allí es muy difícil de leer sin entrar en el espacio de memoria de Java. Para, digamos, una plataforma de tipo PHP no es un enfoque factible, posiblemente la mejor solución sería utilizar un conjunto de variables de entorno cuando se inicie el servidor web. Es cierto que esta es una propuesta más compleja para mantener las contraseñas POP para miles de usuarios potenciales en lugar de, digamos una contraseña de base de datos única, pero el principio es el mismo. En cuanto a una plataforma compartida ... entonces realmente tiene que ir al sistema de archivos (ver también suphp y open_basedir para php).

Sin embargo, la mayor parte de esta complicación desaparece si le pide al usuario que proporcione la contraseña. Proteger los datos de la sesión contra el espionaje es más fácil que una configuración de todo el sistema, aunque todavía hay problemas potenciales aquí. Si necesita autenticar al usuario independientemente de la instalación de un tercero, o si se conecta a múltiples terceros, entonces podría usar la contraseña del usuario como parte de una clave de cifrado para una base de datos almacenada de los tokens de los usuarios.

Pero en lugar de preguntar cómo proteger dicha plataforma, está preguntando cómo reducir el riesgo. Sin embargo, si no controla el mecanismo de autenticación de terceros, entonces no tiene la opción de usar otra cosa que no sea simplemente un nombre de usuario / contraseña.

Entonces, la única otra opción que tienes, además de garantizar la seguridad de dios en el extremo delantero, es aumentar tus datos con potes de miel - entonces si ves algún acceso a los botes de miel entonces sabes que ' Probablemente he sido comprometido.

    
respondido por el symcbean 24.12.2010 - 10:33
fuente

Lea otras preguntas en las etiquetas