almacenar de forma segura las contraseñas cuando el acceso al texto en claro todavía se necesita

Question

Duplicar posibles:
PHP 2-way encryption: I need to store passwords that can be retrieved

Sé que la mejor práctica para el almacenamiento de contraseñas de usuario es almacenar solamente un hash irreversible de la contraseña.

Sin embargo, estoy desarrollando una aplicación en la que necesitaré almacenar la información de inicio de sesión de un usuario para otro servicio web; tendré que registrarlos periódicamente y realizar algunas tareas de mantenimiento. Desafortunadamente, el servicio no ofrece tokens de autorización, así que (muy aprensivamente) tengo que almacenar las contraseñas de manera que pueda acceder a sus valores de texto sin formato. No poseo ni controlo el servicio al que me estoy autenticando, y el único método es "tomar prestado" el nombre de usuario y la contraseña de un usuario y autenticar.

Estoy planeando AES_ENCRYPT las contraseñas en el DB, lo que significa que si alguien de alguna forma puede acceder al DB, no podrán obtener el texto plano. Sin embargo, mi código necesitará tener acceso a la clave para desencriptarlos, por lo tanto, si todo el servidor está comprometido, no hay protección y se revelarán las contraseñas.

Además del cifrado descrito anteriormente, ¿existen algunas mejores prácticas o pasos que puedo tomar para hacerlo de la manera más segura posible?

EDITAR

Yo sé que todo lo que hago, en última instancia, las contraseñas deben ser accesibles en texto plano y por lo que un servidor comprometido significa que las contraseñas serán revelados, pero me gustaría saber qué pasos puedo hacer para mitigar mi riesgo. P.EJ. encriptar el DB me protege en una situación donde el DB está comprometido pero no todo el servidor. Otros pasos mitigantes similares serían muy apreciados.

Answer 1

Sin embargo, estoy desarrollando una aplicación en la que necesitaré almacenar la información de inicio de sesión de un usuario para otro servicio web; tendré que registrarlos periódicamente y realizar algunas tareas de mantenimiento.

OK ... Leí las respuestas y los comentarios, y sobre todo lo que puedo decir es que espero que tenga un equipo legal de crack. Me parece que el servicio que está ofreciendo se basa en la confianza del usuario. Es bueno que sea un interruptor controlado por el usuario, y no algo que se haga de manera útil detrás de sus espaldas, pero creo que usted quiere un acuerdo de servicio realmente sólido sobre esto.

Dicho esto, hay mucha paranoia de seguridad que puede invocar. Tendrá que averiguar cuánto quiere atravesar en función del daño que pueda sufrir su producto, su empresa y sus usuarios si ocurre una interrupción.Aquí es pensamientos:

• de almacenamiento de datos - almacenar las contraseñas lejos de donde un atacante puede obtener en los archivos de acceso muy controlados, una base de datos en una máquina de back-end, etc. Hacer cualquier atacante se vaya a través de capas de defensa. solo para llegar al lugar donde se almacenan los datos. Del mismo modo, tienen protección de red como firewalls y parches de seguridad actualizados. Ninguna cosa funciona aisladamente aquí.
• Encriptación: cualquier técnica de encriptación es una táctica dilatoria: una vez que el atacante tiene sus datos, eventualmente descifrarán su encriptación dado un tiempo infinito. Por lo tanto, en su mayoría, se trata de reducir la velocidad el tiempo suficiente para que el resto del sistema descubra que ha sido pirateado, alertar a los usuarios y darles a los usuarios tiempo para cambiar contraseñas o deshabilitar cuentas. IMO: la criptografía simétrica o asimétrica funcionará, siempre que almacene la clave de forma segura. Siendo yo mismo una persona de PKI, me inclino por la criptografía asimétrica solo porque la entiendo mejor y conozco una serie de soluciones de hardware COTS que hacen posible almacenar mi clave privada de forma extremadamente segura.
• Almacenamiento de claves: su encriptación es tan buena como su almacenamiento de claves. Si la clave está situada justo al lado de los datos cifrados, entonces es lógico pensar que el atacante no necesita romper su criptografía, simplemente usan la clave. Los HSM (módulos de seguridad de hardware) son la mejor opción para el almacenamiento de claves: en los rangos superiores, estas son cajas de seguridad que son inviolables, que mantienen sus claves y ejecutan el cifrado por usted. En el extremo inferior, un token USB o una tarjeta inteligente podría realizar la misma función. Una parte fundamental de esto es que, en última instancia, es mejor si hace que un administrador active el acceso a la clave al inicio del servidor. De lo contrario, terminas con un escenario de gallina y huevo mientras intentas descubrir cómo almacenar de forma segura la contraseña definitiva.
• Detección de intrusos: tenga un buen sistema en funcionamiento que tenga buenas posibilidades de generar alarmas en caso de ser pirateado. Si los datos de su contraseña se ven comprometidos, debe informarles a sus usuarios mucho antes de cualquier amenaza.
• Registro de auditoría: tiene muy buenos registros de quién hizo qué en el sistema, particularmente cerca de sus contraseñas. Si bien puedes crear un sistema bastante impresionante, la amenaza de usuarios privilegiados que hacen algo malo (o tonto) es tan mala como las amenazas externas. Los sistemas de auditoría de high-end típicos rastrean el comportamiento de alto privilegio del usuario de una manera que no puede ser vista o alterada por el usuario de alto privilegio; en cambio, hay una segunda cuenta de "auditor" que solo trata con registros de auditoría y nada más.

Esto es lo más destacado de los puntos más importantes de la seguridad del sistema. Mi punto general es: si realmente quieres proteger las contraseñas de los usuarios, no puedes permitirte el solo pensar en los datos. Simplemente cifrar las contraseñas no es suficiente para proteger realmente a los usuarios y salvaguardar la confianza.

La forma estándar de abordar esto es considerar el costo de explotación frente al costo de protección. Si ambos costos son demasiado altos para el valor de la función, entonces tiene una buena indicación de que no debe molestarse en hacerlo ...

Answer 2

Como dijo, su código finalmente necesitará la clave y, si el servidor está en peligro, también lo serán las contraseñas. No hay manera de evitarlo.

Lo que puede hacer es tener un proxy muy mínimo cuyo único trabajo será tener las contraseñas, escuchar las solicitudes de su aplicación principal, conectarse al servicio en cuestión y devolver la respuesta a su aplicación. Si ese proxy muy simple es todo lo que se ejecuta en un servidor, será mucho menos probable que se vea comprometido que una aplicación complicada que se ejecute en un servidor con muchos servicios.