How can I securely embed a static string (key) in

问题:

I'm looking for a way to securely store an API key in a WP7 application. The key is a string and is currently hard coded into the code (see below). I know that someone with a reflector program could easily view this. Is there a better way to package this key as part of my app? Would a resource be more secure?

string key = "DSVvjankjnersnkaecjnDFSD44VDS23423423rcsedzcadERVSDRFWESDVTsdt";

(This isn't actually the key ;) )

Thank you in advance.

回答1:

Have a look at Safeguard Database Connection Strings and Other Sensitive Settings in Your Code, it is a good read. Your question is under the "Hiding Keys in the Application Source Code" section.

Excerpt:

If you define the key in the application, in addition to obfuscating the assembly, try not to store the actual key bytes in the source code. Instead, implement key-generation logic using persistent characteristics, such as the encryption algorithm, key size, pass phrase, initialization vector, and salt (see an example at Encrypt and Decrypt Data Using a Symmetric (Rijndael) Key). This will introduce an extra layer of indirection, so the key will not be accessible by simply dumping the symbols from the application binary. As long as you do not change key-generation logic and key characteristics, the resulting key is guaranteed to be the same. It may also be a good idea not to use static strings as key-generation characteristics, but rather build them on the fly. Another suggestion would be to treat the assembly the same way as the data store should be treated, that is, by applying the appropriate ACLs. And only use this option as a last resort, when none of the other data protection techniques work and your only alternative is leaving sensitive data unencrypted.

回答2:

I've read through all these answers, and I don't think there is any way you can securely embed this - regardless of where you put it, or how you obfuscate it. As long as its in your XAP and decoded within the application then it will always be available to hacking.

If you need to ship the key inside the xap with a reasonable degree of protection, then I think @maka's answer yields your best bet - obfuscate it as best you can - but don't think this will make you secure - i.e. don't do this for your mobile banking apps!

Alternatively, if you really need security then don't operate solely within the app - use a web server as well. For example, if you were doing a Facebook app and needed to somehow protect your facebook secret key, then you would need to redirect the user from your app to a web page on your server for authentication. That web page would then need to guide the user through the process of getting an access token - and then just that access token (along with the public appid) would need to go back to your app. And for those webservices which require knowledge of the secret key to accompany every call, then I'm afraid every single call will probably need to go via your server.

回答3:

You can encrypt Api key with ProtectedData and then decrypt it in runtime. This is good tutorial how to encrypt data in Windows Phone: Encryption in Mango

回答4:

May be you can encrypt it before hand and save it in app.config. And while reading it decrypt it using the same algorithm.

回答5:

You could use DotFuscator to disable the ability to use reflector. But, this will not allow you to change the key without recompiling.

In the past I've used the following method in other (web/winform-based) software:

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

回答6:

It's not an answer maybe, but sure it's a suggestion:

Store encrpyted key in a db. And store encrypted "db password" in app.config.

1. Use two proper string encrypt/decrypt algorithm, let's say algorithm x and y.
2. Put encrypted db password in app.config before to publish it.
3. Decypt app.config password(algo y) to connect the db for taking new encrpyted string(real one).
4. Close the connection and decyrpt new string with algorithm x if reflector/etc. not running.
5. Use it.
6. Dispose the object that holds the string.