Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Have a look at <a href="https://web.archive.org/web/20080828034844/http://msdn.microsoft.com/en-us/magazine/cc164054.aspx" rel="nofollow">Safeguard Database Connection Strings and Other Sensitive Settings in Your Code</a>, it is a good read. Your question is under the "Hiding Keys in the Application Source Code" section. </p> <p>Excerpt:</p> <blockquote> <p>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 <a href="http://www.obviex.com/samples/Encryption.aspx" rel="nofollow">Encrypt and Decrypt Data Using a Symmetric (Rijndael) Key</a>). 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.</p> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload