M
Mark Rae
Hi,
Picking your collective brains again, this time regarding the storage of the
key used in symmetric encryption.
Let's say you have a requirement to add encryption to a C# project, so you
might choose the TripleDESCryptoServiceProvider class:
http://msdn2.microsoft.com/en-us/li...ptography.tripledescryptoserviceprovider.aspx
No worries - it doesn't present much of a challenge, the MSDN code samples
are easy enough to follow - we're probably looking at a matter of minutes to
knock up an Encryption class with an Ecrypt() and a Decrypt() method.
The text states "This algorithm supports key lengths from 128 bits to 192
bits in increments of 64 bits". Again, not a problem - you need a key to
encrypt the data, and you need the same key to decrypt it again - the
encrypted data can't be (easily) decrypted without the key which was used to
encrypt it in the first place.
Obviously, you're adding encryption to your project as some sort of a
security measure, so you'd imagine that you'd make the key as difficult to
find as possible. But, your app itself needs to know the key, or nothing
works...
Given the premise that ultimately *anything* is hackable, and .NET
assemblies can be disassembled even if obfuscated, where would you typically
store the actual key itself so that your app can use it but hackers will
struggle to find it...?
1) hard-code it into the C# code so that it gets compiled along with the
rest of the code?
2) store it in your app's config file?
3) store it in a resource file?
4) some other storage mechanism?
And, finally, would you use the same storage mechanism for a WinForms app as
for a WebForms app?
Any assistance gratefully received, as always...
Mark
Picking your collective brains again, this time regarding the storage of the
key used in symmetric encryption.
Let's say you have a requirement to add encryption to a C# project, so you
might choose the TripleDESCryptoServiceProvider class:
http://msdn2.microsoft.com/en-us/li...ptography.tripledescryptoserviceprovider.aspx
No worries - it doesn't present much of a challenge, the MSDN code samples
are easy enough to follow - we're probably looking at a matter of minutes to
knock up an Encryption class with an Ecrypt() and a Decrypt() method.
The text states "This algorithm supports key lengths from 128 bits to 192
bits in increments of 64 bits". Again, not a problem - you need a key to
encrypt the data, and you need the same key to decrypt it again - the
encrypted data can't be (easily) decrypted without the key which was used to
encrypt it in the first place.
Obviously, you're adding encryption to your project as some sort of a
security measure, so you'd imagine that you'd make the key as difficult to
find as possible. But, your app itself needs to know the key, or nothing
works...
Given the premise that ultimately *anything* is hackable, and .NET
assemblies can be disassembled even if obfuscated, where would you typically
store the actual key itself so that your app can use it but hackers will
struggle to find it...?
1) hard-code it into the C# code so that it gets compiled along with the
rest of the code?
2) store it in your app's config file?
3) store it in a resource file?
4) some other storage mechanism?
And, finally, would you use the same storage mechanism for a WinForms app as
for a WebForms app?
Any assistance gratefully received, as always...
Mark