¿Cómo almacenar la frase de contraseña en esta situación?

Primero, el inicio de sesión se debe emitir por cliente, por lo que se puede cambiar si se filtra o cancelar cuando se revoca el acceso de un cliente al servicio. Esto reduce las consecuencias de la pérdida de la contraseña al tamaño más pequeño, en lugar de perder todo cuando un cliente se ve comprometido o se deshace de él.

Una vez que haya hecho eso, su problema es simplemente almacenar una contraseña que se utiliza para este único cliente con este único servicio. Este es un problema bien conocido con soluciones conocidas. Esencialmente, debes asumir que el sistema operativo es seguro. (Si no es así, tiene problemas más graves). Así que guárdelo en un archivo, el registro, etc., y protéjalo con una ACL. Si lo desea, puede agregar ofuscación además de eso, o usar CryptProtectData o similar, que puede proporcionar cierta protección contra atacantes no sofisticados.

Pero la conclusión es que debe aceptar que emitir, revocar y restablecer las credenciales será una parte normal de su operación. También querrá supervisar el uso del servicio para que pueda detectar cuándo se han filtrado las credenciales.

Esto es difícil de lograr sin dejar un nivel de riesgo razonablemente significativo (si el anfitrión se viera comprometido de alguna manera), aunque puede ser mitigado en cierta medida.

Las credenciales HTTP deben cifrarse a través de un algoritmo simétrico fuerte (y bien establecido), que requeriría una contraseña para el descifrado. Dado que tendrá que descifrar la contraseña sin que haya un operador presente, la clave deberá estar disponible en algún lugar, lo que es la debilidad de este método. Recomendaría no codificar de forma rígida ninguno de estos detalles, ya que todos podrían revelarse si alguien tuviera en sus manos los archivos de la aplicación. En su lugar, recomendaría que se pidan al usuario las credenciales de HTTP y una contraseña de cifrado durante la instalación / primer uso. La aplicación solicitará la contraseña de cifrado cada vez que se inicie, que se almacenará en la memoria hasta que finalice el proceso de la aplicación. Esto requeriría un operador durante la primera instalación y para cada reinicio, etc.

(Nb Se recomienda que se usen matrices de caracteres para las variables de contraseña en lugar de cadenas debido a la recolección de basura en Java. Vea aquí: enlace )

Sin embargo, una solución más conveniente, que se basa en que la aplicación se use únicamente en Windows, pero que básicamente gestione todo lo anterior para usted, sería utilizar DPAPI . Básicamente, esto encripta y almacena las credenciales usando los detalles de la cuenta de Windows, por lo que la aplicación debería poder recuperar las credenciales HTTP siempre que las ejecute un usuario que las haya almacenado a través de DPAPI. Esto tiene puntos débiles similares a los de la solución local, pero evita los inconvenientes de implementar su propio sistema de cifrado.

Aparentemente, su principal vulnerabilidad en este modelo es la red: gastar tiempo y dinero en tratar de almacenar datos que viajarán en texto claro es una pérdida de tiempo (y dinero).

Por lo general, tratará de resolver ese tipo de problema agregando una capa de seguridad alrededor de la parte vulnerable: si no puede hacer que el sistema remoto use HTTPS, use una VPN que termine lo más cerca posible del objetivo servidor (porque cualquier persona que tenga acceso a la red entre ese punto final de VPN y el servidor HTTP podrá obtener los datos de texto sin cifrar).

Otra opción es colocar ambos sistemas en la misma red reforzada. (Por lo general, esto solo tiene sentido si ya tiene una red disponible).

Una vez que haya asegurado la red, entonces puede pensar en proteger estas claves (aunque, en su caso, podría ser inútil si el sistema remoto no trata esta clave de manera segura).

Codifíquelo en Base64, mantenga el resultado en una variable y descodifíquelo cuando sea necesario. Eso mantendrá alejados a los guionistas, pero no al resto.