¿Cómo puedo incrustar de forma segura una cadena estática (clave) en C#?

Question

Estoy buscando una manera de almacenar de forma segura una clave API en una aplicación WP7. La clave es una cadena y actualmente está codificada en el código (ver a continuación). Sé que alguien con un programa reflector podría ver esto fácilmente. ¿Hay una mejor manera de empaquetar esta clave como parte de mi aplicación? ¿Sería un recurso más seguro?

string key = "DSVvjankjnersnkaecjnDFSD44VDS23423423rcsedzcadERVSDRFWESDVTsdt"; 

(Esto no es realmente la clave;))

gracias de antemano.

Answer 1

Eche un vistazo a Safeguard Database Connection Strings and Other Sensitive Settings in Your Code, es una buena lectura. Su pregunta se encuentra en la sección "Ocultar claves en el código fuente de la aplicación".

Extracto:

Si se define la clave en la aplicación, además de ofuscar la asamblea, trate de no almacenar los bytes clave real en el código fuente. En su lugar, implemente la lógica de generación de claves utilizando características persistentes, como el algoritmo de cifrado, el tamaño de la clave, la frase de contraseña, el vector de inicialización y la sal (vea un ejemplo en Encrypt and Decrypt Data Using a Symmetric (Rijndael) Key). Esto introducirá una capa adicional de direccionamiento indirecto, por lo que no se podrá acceder a la clave simplemente descartando los símbolos del binario de la aplicación. Siempre que no cambie la lógica de generación de claves y las características clave, se garantiza que la clave resultante será la misma. También puede ser una buena idea no usar cadenas estáticas como características de generación de claves, sino construirlas sobre la marcha. Otra sugerencia sería tratar el ensamblaje de la misma manera que se debe tratar el almacén de datos, es decir, aplicando las ACL apropiadas. Y solo use esta opción como último recurso, cuando ninguna de las otras técnicas de protección de datos funciona y su única alternativa es dejar datos confidenciales sin cifrar.

Answer 2

Puede cifrar Api llave con ProtectedData y luego descifrarlo en tiempo de ejecución. Este es un buen tutorial sobre cómo cifrar los datos en el teléfono de Windows: Encryption in Mango

Answer 3

Puede ser que pueda cifrarlo antes y guardarlo en app.config. Y mientras lo lee, descifrelo usando el mismo algoritmo.

Answer 4

Puede usar DotFuscator para desactivar la capacidad de utilizar el reflector. Pero esto no le permitirá cambiar la clave sin volver a compilar.

En el pasado he utilizado el siguiente método en el software de otra (web/basadas en WinForm):

http://weblogs.asp.net/jgalloway/archive/2008/04/13/encrypting-passwords-in-a-net-app-config-file.aspx

Answer 5

No es una respuesta tal vez, pero seguro de que es una sugerencia:

Almacene la clave encriptada en un db. Y almacene la "contraseña de db" cifrada en app.config.

1. Utilice dos algoritmos adecuados para cifrar/descifrar cadenas, digamos algoritmo x e y.
2. Ponga la contraseña de db cifrada en app.config antes de publicarla.
3. Decypt app.config contraseña (algo y) para conectar el db para tomar nueva cadena encrpyted (real).
4. Cerrar la conexión y desencriptar nueva cadena con algoritmo x si reflector/etc. no corras.
5. Úselo.
6. Deseche el objeto que contiene la cadena.

Answer 6

He leído todas estas respuestas, y no creo que haya ninguna forma de insertarlas de manera segura, independientemente de dónde las coloque o de cómo las oculte. Siempre y cuando esté en su XAP y decodificado dentro de la aplicación, siempre estará disponible para hackear.

Si necesita enviar la clave dentro del xap con un grado razonable de protección, entonces creo que la respuesta de @maka es la mejor: ofuscarlo lo mejor que pueda, pero no crea que esto lo haga seguro. es decir, ¡no hagas esto para tus aplicaciones de banca móvil!

Alternativamente, si realmente necesita seguridad, entonces no opere únicamente dentro de la aplicación, use un servidor web también. Por ejemplo, si estuvieras haciendo una aplicación de Facebook y necesitaras de alguna manera proteger tu clave secreta de Facebook, entonces necesitarías redirigir al usuario desde tu aplicación a una página web en tu servidor para autenticación. Esa página web necesitaría guiar al usuario a lo largo del proceso de obtención de un token de acceso, y luego ese token de acceso (junto con la aplicación pública) debería volver a su aplicación. Y para aquellos servicios web que requieren el conocimiento de la clave secreta para acompañar cada llamada, me temo que cada llamada probablemente deba pasar por su servidor.