Tengo un caso en mis manos donde mi servidor necesita realizar llamadas API automatizadas que requieren autenticación. Por lo tanto, el servidor necesitará conocer las contraseñas literales para realizar esas llamadas.
¿Qué opciones tengo para garantizar la seguridad de esas contraseñas?
La mejor manera de almacenar contraseñas de forma recuperable probablemente sería cifrarlas con un cifrado simétrico. Tenga las contraseñas almacenadas en el dispositivo que tiene la intención de usarlas solo en su forma cifrada y, tal vez, al iniciarse el servicio tenga la clave que se usará para descifrar las contraseñas de la API a través de métodos externos usted mismo ingresando una contraseña, recuperándola desde una computadora externa que no esté conectada a la red, etc.).
Una vez que la clave para descifrar las contraseñas de la API se haya cargado solo en la memoria y no se haya colocado en el disco, puede usarla para descifrar las contraseñas de la API según sea necesario. Asegúrese de mantener las contraseñas de texto simple en la memoria y sobreescribalas una vez que se hayan utilizado.
Bueno, si es una contraseña literal, ¿es esto debido a alguna API que la requirió una vez? Normalmente, las formas más modernas de autenticación omiten una contraseña directa y uno redirigiría a un usuario a un mecanismo de autenticación de terceros, junto con una clave API. El proveedor de Ali le devolvería a su sitio un token de autenticación que podría usar para las llamadas a la API.
Si se trata de una contraseña privada (por ejemplo, algo similar a una base de datos SAP), simplemente puede bloquear el archivo.
Pero si tienes que pedirle al usuario su contraseña directamente para poder usar algún otro código de backend, entonces simplemente me huele un poco raro y mi instinto diría que tiene que haber una mejor manera.
Almacenar una contraseña en forma literal generalmente es una mala idea. Si tiene las manos atadas, intente, como mínimo, calcular la contraseña sobre la marcha utilizando un código confuso; esto al menos frustrará a los piratas informáticos automatizados y de bajo nivel si se revelara el binario.
La primera de ninguna solución estará en el nivel más esperado para el almacenamiento de contraseñas, ya que usted, como servicio, necesitará acceder a las contraseñas del cliente.
Como usted no proporciona los vectores de ataque, asumiré que desea protegerse contra lo más común / más fácil de lograr, que sería el acceso a la base de datos. (El acceso de lectura es específico, pero para esta situación no importa realmente).
Para protegerse contra esto, cifre las contraseñas antes de enviarlas al servidor de base de datos y NO almacene la clave de cifrado en la base de datos o en el servidor de base de datos. Argumentaría tener un servidor que solo maneje el cifrado / descifrado y las llamadas a la API. Luego, tenga las reglas de firewall tan sólidas como sea posible "a su alrededor", lo ideal sería que no permitiera que este servidor acceda directamente al servidor de base de datos para limitar su comunicación a otro servidor de aplicaciones suyo y, por supuesto, el acceso necesario para la API. llamadas.
Este enfoque lo haría para que un atacante deba violar esta máquina de cifrado / descifrado, y además deberá violar su base de datos (u otro servidor de aplicaciones) si desea obtener contraseñas para un usuario específico. También ayuda a enfocar sus otras medidas de protección alrededor de este servidor y código. Como la auditoría de código de la aplicación que se ejecuta en este servidor, por ejemplo, otra razón para mantener la funcionalidad de esta aplicación lo más limitada posible.
Dado que no especifica el modelo de amenaza o el entorno, tengo que hacer suposiciones contra las que quiere protegerse. Supongo que su canal de comunicación es seguro y le preocupa que un atacante comprometa las contraseñas del servidor.
Primero, endurece tu servidor correctamente. Si el lugar donde se almacenan las contraseñas está lo suficientemente protegido con permisos de archivo, almacenado en la ubicación inaccesible adecuada, etc., ya ha dificultado mucho la vida de los atacantes.
En segundo lugar, puede almacenar las contraseñas cifradas y descifrarlas sobre la marcha o mantener una copia desencriptada en la memoria volátil. Pero esto solo mueve la portería. Si el atacante puede obtener la contraseña utilizada para descifrar o acceder a la ubicación donde está almacenada sin cifrar, también se acabó el juego.
En tercer lugar, si la contraseña nunca se usa directamente, por ejemplo. Si el servidor solo necesita saberlo para obtener una clave de sesión, puede descargar todo a un módulo seguro.
En cuarto lugar, podrías hacer tu propio hombre en el medio y hacer que un proxy inyecte la contraseña. Nuevamente, esto mueve la portería al servidor proxy y abre un par de otros botes de gusanos, pero el proxy probablemente sea mucho menos complejo que el servidor y, por lo tanto, más fácil de endurecer.
tl; dr: Hay un par de opciones, pero no das suficiente información específica para obtener una respuesta realmente práctica.
Lea otras preguntas en las etiquetas password-management server