security - programas - Evite que los programadores conozcan las contraseñas utilizadas en tiempo de ejecución

ver contraseñas guardadas en internet explorer sin programas (15)

¿No debería haber al menos una persona que tenga acceso a una contraseña o la clave? Nuestros desarrolladores no tienen acceso a servidores de producción. Eso les permite a los chicos del sistema, a quienes se les permite conocer las contraseñas, establecer las contraseñas cuando implementan el software.

Codifique el software para que sea configurable y luego mantenga a sus desarrolladores fuera.

Mi aplicación se conecta a un servidor FTP con un nombre de usuario y contraseña. Puedo crear una rutina de encriptación para encriptar y descifrar la contraseña, pero cualquiera que tenga acceso al código fuente y la contraseña encriptada puede descifrar la contraseña.

¿Hay alguna manera fácil de evitar que todo ser humano conozca la contraseña completa utilizada por una aplicación? (Creo que está bien si varias personas conocen parte de la contraseña).

EDITAR: Sé que FTP no es seguro. Idealmente, me gustaría una técnica que funcione en cualquier situación donde se requiera un nombre de usuario y contraseña (por ejemplo, una conexión de base de datos).

En esencia, no. Puedes dificultarlo, pero es posible atacar cualquier esquema que tenga código ejecutándose en la computadora de otra persona. ¿Cómo sabe el servidor FTP que está hablando con su aplicación, y no alguien que ha pirateado lo que necesita de su aplicación?

Independientemente del tipo de encriptación que utilice, la contraseña debe estar encriptada antes de que su aplicación pueda conectarse al ftp. Cualquier usuario puede ejecutar su aplicación en un depurador, rastrear hasta ese punto y luego elegir la contraseña de la memoria. De esa manera, la seguridad completa para su escenario es imposible.

Dicho esto, puede poner la contraseña cifrada en un archivo de configuración que se lee durante el tiempo de ejecución. Permita que los desarrolladores se conecten a un ftp diferente (o con una cuenta diferente que luego se elimine) y ponga la contraseña cifrada que desea proteger en el archivo de configuración cuando implemente la aplicación.

No, no hay forma de hacerlo de forma segura. ftp no es un protocolo seguro de todos modos, por lo que las personas no necesitarían el código fuente para ver su nombre de usuario y contraseña, solo un sniffer de red local. Podrías evitar ese problema usando tunneling ssh, pero si envías el código fuente siempre será trivial para las personas que tienen acceso a él obtener el nombre de usuario y la contraseña. Incluso sin fuente e incluso con un protocolo seguro, un atacante dedicado con un desensamblador / depurador y un poco de tiempo libre aún podrán obtener esta información del ejecutable. Si un nombre de usuario y contraseña deben ser seguros, no los incluya en el código, ¡incluso si están ofuscados!

No, no hay una manera fácil: puedes ofuscar las cosas tanto como quieras, pero si la contraseña de texto plano está disponible para la aplicación en cualquier punto, sin requerir acceso a ningún recurso que no sea su propio código fuente, puede ser extraído por cualquier ser humano con acceso a ese mismo código fuente también.

Al usar un protocolo como FTP, todo el ejercicio es un poco inútil de todos modos: cualquiera que sea capaz de descargar Wireshark puede oler las credenciales del cable de red en segundos, si no menos.

Pasos para resolver adecuadamente su problema:

Cambiar a un protocolo seguro, como SFTP o FTP + SSL
Utilice la autenticación de clave pública en lugar de una contraseña (tanto SFTP como FTP + SSL admiten esto, aunque de maneras ligeramente diferentes)
Proporcione a cada implementación del software una copia (de preferencia privada, para que pueda detectar el intercambio de credenciales y deshabilite las cuentas comprometidas) de la clave privada / certificado requerido para iniciar sesión
Almacene la clave / certificado privado de la manera más segura posible en la plataforma en la que se está ejecutando. En Windows, esto significa usar la Tienda de certificados: consulte este artículo de MSDN Magazine para obtener una introducción agradable.

EDITAR (después de la modificación de la pregunta original): el primer párrafo de mi respuesta se aplica igualmente a cosas como contraseñas de bases de datos, etc. La solución para esas situaciones se vuelve aún más específica de la plataforma. Si su combinación particular de base de datos / lo que sea / SO no admite inicios de sesión seguros, no hay mucho que pueda hacer.

Por ejemplo: en Windows, SQL Server admite la autenticación NTLM, lo que le permite establecer derechos de acceso a la base de datos basados en cuentas de Windows existentes, proporcionándole un almacenamiento seguro automático y la transmisión de contraseñas, que es relativamente difícil de evitar. Si no se puede usar la autenticación NTLM, lo mejor que puede hacer (como es la práctica recomendada en .NET Framework) es almacenar la contraseña, cifrada con una clave específica de la máquina, en un archivo de configuración. Sin embargo, esa "protección" se pasa de manera trivial utilizando un depurador, ya que la contraseña de texto plano es necesaria en algún momento.

No. Todo lo que un usuario de la aplicación tiene que hacer es husmear su propio tráfico de red (fácil de hacer con Wireshark o similar).

Realmente necesita una forma de darle a cada usuario un token único de algún tipo.

Editar - más información:

Cualquier sistema que dependa de la información de inicio de sesión "secreta" que sea la misma para cada copia de la aplicación está viciado por el diseño. Para mantener las cosas seguras, cada instalación de su aplicación debe tener un secreto único que utiliza para autenticarse con el servidor. La forma de lograr eso depende de cómo licencia / distribuye su aplicación. Así es como lo haría. (Realice todas las comunicaciones a través de una conexión SSL).

La aplicación se inicia por primera vez; ve que no tiene guardada la información de autenticación.
La aplicación le solicita un código de registro, una dirección de correo electrónico y / o la forma en que desea identificar a sus usuarios.
La aplicación genera un par de llaves público / privado y envía la clave pública con su información de identificación del paso 2 al servidor.
El servidor recuerda tu clave y la usa para identificar tu aplicación a partir de ahora.

El paso alternativo 3 es: la aplicación envía información desde el paso 2 y el servidor envía una firma hash de información + sal. La firma Hash es ahora la clave de su aplicación.

Lo importante es que no hay un compartido "secreto" entre todos sus usuarios.

Probé muchos métodos, y no creo que el cifrado sea el camino en este caso. En su lugar, almacene la contraseña en un archivo de configuración, como web.config / app.config / etc o el registro de Windows, o un archivo en / etc o en cualquier otro lugar al que los desarrolladores no tengan acceso (en el entorno de producción) , pero lo hace.

Supongo que ya has visto suficientes respuestas de "no". Me gustaría señalar (sin responder directamente a su pregunta) que un problema similar ha sido (casi) resuelto con jdbc-datasources en servidores Web / Application: estos son recursos, básicamente fábricas de conexiones, que proporcionan bases de datos ya conectadas. conexiones sin la aplicación que necesita preocuparse por la configuración de la conexión, incluidos los nombres y las contraseñas. La conexión es establecida por el servidor de aplicaciones, el servidor de aplicaciones también lee el archivo de configuración y conoce la contraseña.

No conozco el vocabulario para esto en otros entornos (o aplicabilidad), pero como me preguntas por el idioma y no estoy respondiendo directamente a tus preguntas, creo que está bien limitar el ejemplo a Java.

Si encuentra / escribe una abstracción similar que proporciona la conexión ftp, puede evitar que los programadores con código fuente conozcan las contraseñas (porque solo se utilizan objetos de conexión proporcionados por algún "contenedor"). Sin embargo, no ayudará contra las escuchas telefónicas o las personas con acceso de depuración a la aplicación en ejecución.

Espero que esto ayude, incluso si no responde directamente y no es estricto "sí" ;-)

Una forma de hacerlo es alojar la aplicación en un servidor. Si la contraseña se almacena en un área restringida del servidor, aquellos que usen la aplicación no tendrán acceso a ella. De hecho, no tendrán acceso a la aplicación, excepto a través de la interfaz proporcionada. Esta es una razón por la cual las aplicaciones web se están volviendo tan populares.

En este caso particular, donde el código fuente aún está disponible para ellos, solo tiene que asegurarse de que la contraseña no se almacena con el código fuente, sino solo en el servidor seguro, y solo puede acceder a ella la cuenta que aloja la aplicación en el servidor.

la respuesta real es no. La comunicación estándar del servidor cliente FTP realmente pasa el nombre de usuario y la contraseña a través de la red sin cifrar. Por lo tanto, incluso si intenta utilizar algún esquema para cifrar los datos reales dentro de su aplicación, cualquier persona con una copia de Ethereal podrá olerlo.

solo para lanzar ideas:

almacene la contraseña en el binario, en el lugar que le asignó.
la contraseña puede cambiar según la hora (día) o algo así, pero si ejecutan el código, también pueden obtenerlo.
tal vez hacer algo con clave pública / clave privada. (La firma en encriptación puede identificar al usuario. Esta información se puede recuperar en tiempo de ejecución, creo que desde su clave. Es como un desafío, pero necesitaría construir / programar otra servidor solo para esta parte de autenticación. Tal vez haya formas conocidas más aceptadas industrialmente ...

ftp por cierto no es seguro. Necesitarás sftp o ftps para evitar transmitir texto claro.

No estoy seguro de lo que necesita ... si busca una forma de codificar una contraseña privada, desestime mi comentario.

Pero si está buscando una forma de almacenar contraseña ...

Creo que lo que estás buscando es guardar un hash de la contraseña en lugar de la contraseña misma. De esta forma, incluso si un programador tiene su algoritmo de verificación de contraseña y el hash de contraseña de la base de datos, no podrá descifrar la contraseña.

Tal vez esta respuesta te ayude dependiendo de tu entorno. Sin embargo, al final, porque las personas están involucradas en el proceso, la respuesta es "no muy probable".

Guarde la combinación de nombre de usuario / contraseña en un archivo de configuración.
Configure un servidor provisional con un nombre de usuario / contraseña, el servidor de prueba con otro y el servidor del producto con otro nombre de usuario / contraseña.
La contraseña en el archivo de configuración (que todos los programadores conocerán) es para el servidor de transferencia. El nombre de usuario / contraseña dado al grupo de prueba es para el servidor de prueba.
Asegúrese de que el servidor de producción / prueba tenga un nombre de usuario / contraseña diferente.
Distribuya el archivo de configuración con el nombre de usuario / contraseña de producción correcto con el producto.

Lo que hace es una gran causa de paranoia, paranoia inútil. Si no confía en las personas a su cargo para mantener sus datos seguros, consiga a otras personas.

El problema aquí no es uno que pueda resolver usando software, es un problema de recursos humanos. Dos personas, cada una con parte de la contraseña, seguramente se encontrarán por ejemplo, en cuyo caso dos personas ahora sabrán la contraseña completa.

Y como usted mismo señala, incluso si tuviera que hacerlo para que ninguna persona tenga la contraseña (excepto, por supuesto, la persona que realmente establece la contraseña para el servidor en primer lugar ...) aún es fácil de interceptar a través del cable .

Es el mismo viejo problema de "No quiero que nadie tenga acceso a la computadora", lo cual solo se puede hacer desenchufando la computadora de todo, soldandola en una caja de acero, vertiendo hormigón sobre ella y disparándola al espacio profundo.

Puedes consultar mi vieja pregunta y las respuestas aquí. ¿Cómo almacenar contraseñas en la aplicación Winforms? . Pero, esperando algunas otras ideas también.