¿Es seguro almacenar una contraseña en el código compilado? [duplicar]

No, no es seguro.

Cualquier aplicación compilada puede ser desmontada y examinada. El código de bytes CIL generado por su compilador de C # se puede rastrear instrucción por instrucción al igual que cualquier otro lenguaje de programación. Cuando codifique su clave criptográfica, aparecerá en algún lugar del ensamblaje. (lo mismo se aplica al código de máquina generado por compiladores "reales", por cierto). No es si alguien encuentra su clave, la pregunta es cuándo .

Puede codificar su clave, pero el algoritmo de codificación también debe ser parte de su ensamblaje, para que el atacante pueda encontrarlo y utilizarlo.

Puede usar un ofuscador de código que hace que el ensamblaje sea menos legible, pero que generalmente afecta negativamente el rendimiento y también es un obstáculo adicional que le costará más tiempo al atacante pero no evitará que lo encuentren cuando sean lo suficientemente diligentes.

Para agregar a la respuesta de Philipp:

No es seguro, ni puede hacerse seguro, sin importar cuánto esfuerzo le pongas.

Pero puede hacer que sea más fácil lidiar con los problemas. Si almacena la clave en un archivo externo en lugar de en algún lugar del código de su programa, es mucho más fácil cambiarlo. Por lo tanto, si bien no puede evitar que la clave sea robada y que no se descifren los datos, puede facilitar el cambio regular de la clave, de modo que un atacante debe recuperar periódicamente el acceso a la clave si desea seguir leyendo los datos cifrados. . Esto aumenta las posibilidades de que lo detecten (podría tropezar con algún tipo de sistema de detección de intrusos tarde o temprano, o cometer un error estúpido)

Separar la clave y la aplicación también facilita la protección de la clave: ahora solo tiene que proteger un archivo pequeño y no tiene que preocuparse por dónde se almacenan el código fuente y el código binario de la aplicación (piense en los sistemas de control de versiones, paquetes administradores, entornos de compilación automatizados, copias de seguridad, etc.).

Mantener la clave en un archivo externo también es una buena idea, ya que dependiendo de la plataforma en la que esté ejecutando, su aplicación puede comenzar con permisos elevados que le permiten leer la clave, y luego eliminar estos permisos para que en ejecución, ya no tendrá acceso a la clave almacenada. Esto evitará algunos tipos de ataques, aunque, por supuesto, un atacante sofisticado siempre puede extraer la clave de la memoria de la aplicación.

Dependiendo de lo que haga su aplicación, también podría ser posible reducir significativamente la superficie de ataque. Si una parte de la aplicación solo escribe datos secretos, puede dividir la aplicación en dos partes y usar la criptografía de clave pública para no tener que preocuparse por la primera aplicación, la que solo necesita escribir datos, pero no volver a leerlos. En ese caso, le das a la primera aplicación una clave pública para cifrar una clave de sesión, que usas para escribir los datos secretos. Ahora solo tiene que proteger la segunda aplicación, que lee los datos, o más bien, la clave privada a la que tiene acceso esta aplicación.

No, no es seguro y necesitas cambiar tu arquitectura si quieres asegurarla.

Su arquitectura actual

Client application < -- > Web services

Para comunicarse con los servicios web, necesita una contraseña secreta que el usuario no debe saber. Pero como la aplicación cliente está instalada en la computadora del usuario, no hay forma de proteger esa contraseña como mencionan las otras respuestas.

Ahora, para proteger estas contraseñas, necesita cambiar su arquitectura.

Una nueva arquitectura

Client application < -- > Intermediate Server < -- > Web services

Ahora puede almacenar de forma segura las contraseñas de los servicios web en el servidor intermedio. Por lo general, lo hace utilizando un archivo de configuración externo a su código fuente para el servidor intermedio.

Y...

Ahora, la pregunta es ¿cómo protege el acceso al servidor intermedio? Pero esa probablemente debería ser otra pregunta.

Como explicaron las otras respuestas, su enfoque es inseguro. Sin embargo, para agregar a las otras respuestas, hay un concepto que intenta resolver un problema similar (al menos desde un punto de vista práctico; principalmente, si el secreto está en posesión del atacante, aunque esté ofuscado, debe considerarlo libremente). utilizable por el atacante), que se llama criptografía de caja blanca. Ver por ejemplo esta pregunta y whiteboxcrypto.com :

  

El desafío que trata la criptografía de caja blanca es implementar un algoritmo criptográfico en el software de tal manera que los activos criptográficos permanezcan seguros incluso cuando están sujetos a ataques de caja blanca.

El punto es que no puedes usar conceptos y métodos "clásicos", por ejemplo, “Codifique la contraseña en mi clase” mientras escribe. Necesitará "hornear" el algoritmo de encriptación y la clave en una transformación "confusa".