it-swarm-es.com

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

Supongamos que hay una aplicación web multiusuario que requiere acceso al buzón de correo 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 obtiene acceso a dicho sistema, podría robar toneladas de buzones de correo de los usuarios. ¿Hay alguna forma 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, se pueden restringir y pueden caducar en masa fácilmente si sucede algo malo. Pero todo esto no está disponible para los servidores de correo. ¿Alguna sugerencia sobre una buena manera (si existe) de almacenar dicha información de una manera más segura?

9
StasM

La experiencia muestra que si un sitio como este está 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. Note bien las respuestas en esta extensa discusión (sobre un objetivo algo diferente):

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

6
nealmcb

Como dices, este es un punto débil potencial. Pero la forma de solucionarlo 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, entonces 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 volver a leer sin entrar en el espacio de memoria de Java. Para, digamos, una plataforma de tipo PHP este no es un enfoque factible, posiblemente la mejor solución sería usar un conjunto de variables de entorno cuando se inicia el servidor web. Es cierto que este es un enfoque más complejo propuesta para mantener las contraseñas POP para miles de usuarios potenciales en lugar de, digamos, una sola contraseña de base de datos, 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 de espionaje es más fácil que una configuración de todo el sistema, aunque todavía existen problemas potenciales aquí. Si necesita autenticar al usuario independientemente de la instalación de un tercero, o si se conecta a varios terceros, puede 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, pregunta cómo reducir el riesgo. Sin embargo, si no controla el mecanismo de autenticación de terceros, no tiene la opción de usar nada más que simplemente un nombre de usuario/contraseña.

Entonces, la única otra opción que tiene, aparte de garantizar la seguridad divina en la parte delantera, es aumentar sus datos con botes de miel; luego, si ve algún acceso a los botes de miel, entonces sabe que probablemente ha estado comprometidos.

3
symcbean