Métodos para almacenar contraseñas de texto simple en un cliente

Como es habitual en este tipo de preguntas, comencemos por definir un Modelo de amenaza . La Electronic Frontier Foundation tiene un artículo llamado Evaluando su modelo de amenaza donde te piden que consideres tres preguntas ( cursiva mía ):

  

1. ¿Qué está protegiendo? (Los datos, las comunicaciones y otras cosas que podrían causarle problemas si se utilizan incorrectamente)
  
2. ¿De quién lo estás protegiendo? (Las personas, organizaciones y actores criminales que podrían buscar acceder a esas cosas)
  
3. ¿Cuántos recursos puede invertir para protegerlo? (El dinero, el tiempo y la conveniencia que está dispuesto a prescindir de proteger esas cosas)
  

Suena como:

1. Está protegiendo A) los datos que ya son públicos, al menos dentro de su organización, y B) un nombre de usuario / contraseña para este contenido.
2. Lo está protegiendo de los piratas informáticos que ingresan a su servidor, que está enterrado profundamente dentro de la red local, pero excluyendo como amenaza a cualquier persona con acceso físico a la oficina (¿y presumiblemente también acceso a la red?). Entonces, ¿contra qué actores de amenazas están tratando de protegerse?
3. Parece que estás dispuesto a invertir un poco de esfuerzo en proteger el nombre de usuario / contraseña, pero no puedes tener un bebé que lo cuide 24/7.

Como se señaló en la pregunta y en los comentarios, el software necesita acceso al nombre de usuario / contraseña, por lo que lo mejor que puede hacer es cifrarlo en el disco y requerir que un humano ingrese la contraseña de descifrado de vez en cuando. Hay algunas opciones sobre cómo hacer esto dependiendo de su modelo de amenaza / qué tan paranoico quiere ser:

1. Use openssl (o alguna otra crypto lib) en su aplicación para leer el archivo cifrado del disco y pedirle a un humano la contraseña de descifrado cada vez que el raspador lo necesite, luego borrarlo de la memoria (esto protege contra usuarios malintencionados) comprometió el servidor donde se está ejecutando).
2. Use openssl como anteriormente, pero solo solicite una contraseña de descifrado al iniciar el proceso.
3. Encuentre algún truco de Linux que lo proteja dentro del directorio de inicio del usuario (algo equivalente a API de protección de datos de Microsoft ).
4. Si se trata de un servidor de un solo usuario o si no le preocupa tratar a otros usuarios como maliciosos, habilite el cifrado completo del disco en la máquina para que solicite una contraseña durante el inicio. Esto realmente solo protege contra el robo físico del servidor, pero tal vez sea apropiado para su modelo de amenaza.

También debe crear una cuenta de usuario separada para el raspador en lugar de darle las credenciales de un usuario humano, esta A) ayuda a auditar los registros para detectar comportamientos extraños causados por el raspador, B) protege la contraseña de esa persona contra filtraciones, especialmente si reutilizan esa contraseña para otras cuentas, C) le permite suspender fácilmente la cuenta del raspador si sospecha un compromiso.

La solución rápida y fácil (pero incorrecta) es tener una contraseña maestra para cifrar los inicios de sesión y las contraseñas. Tendrá que escribir esta contraseña cada vez que ejecute el script. Si no desea tener que escribirlo cada vez, puede ver esta pregunta para otras opciones.

La forma correcta de hacerlo es dirigirse al administrador de su sitio interno y solicitarles credenciales de raspado web que le otorguen todos los derechos de acceso adecuados para raspar lo que necesita. Nunca deberías tener acceso a los inicios de sesión y contraseñas de otros. Es peligroso para la empresa y una responsabilidad para usted si algo malo sucede. Desafortunadamente, esto puede no ser una opción, ya que requiere la cooperación de otra persona.

  

Mi pregunta: ¿Cómo puedo hacer que las contraseñas de texto plano almacenadas en el cliente tengan el menor riesgo posible, dado que es imposible evitarlas por completo?

Si realmente necesita almacenarlo en el disco, tal vez podría explicar cuál es el motivo. Esto podría hacer que sea más fácil dar una respuesta precisa. ¿Podría suponer que lo almacena sin cifrar porque lo tiene codificado en el script? ¿Y el script se almacena en el disco? En este caso, en lugar de codificar la contraseña, puede leerla desde una variable de entorno. Esto es más seguro que la codificación directa directamente en el script.

Sugiero usar algo como keepass, almacenar el nombre de usuario y la contraseña en él y bloquearlo con la contraseña maestra (O simplemente puede cifrar la contraseña del nombre de usuario utilizando OpenSSL), ahora necesita proteger su contraseña maestra.

Puede poner la contraseña maestra en el almacén de claves de Windows o en el conjunto de claves de Linux y asociarla a la cuenta de servicio en el sistema que puede ejecutar su secuencia de comandos automatizada y liberar la contraseña maestra para acceder al nombre de usuario y la contraseña.