Push in the right direction on security...

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

JJ - 18 Sep 2007 16:08 GMT

First, I want to confess I am not security expert by any stretch of the
imagination, but I have been tasked with securing our dB connection
information for our distributed windows applications. Essentially I would
like to store the information in an encrypted XML file, but the problem I
can't solve is how do I protect the key/decryption code. I know I can store
the key within the encrypted file, but anyone who has access to our code
would then have access to the decryption logic. It seems to me anyone with
ildasm or even reflector would be able to view the logic. Am I completely
upside down on this?

Thanks in advance.

Reply to this Message

Ben Schwehn - 18 Sep 2007 16:37 GMT

> First, I want to confess I am not security expert by any stretch of the
> imagination, but I have been tasked with securing our dB connection
[quoted text clipped - 5 lines]
> ildasm or even reflector would be able to view the logic. Am I completely
> upside down on this?

It is not possible to 100% secure a connection string on the client. if
the App-Code can read it, so can a sufficiently determinded attacker, at
least if the attacker has physical access to the machine as in your
scenario.

This being said, there are ways to make it more difficult, a common (and
simple) one seems to be using SectionInformation.ProtectSection()

If you restirct the db user rights so that it can't do anything on the
db that the application is not supposted to do, protecting the
connection string is much less important.

Or -- in a windows network -- perhaps use trusted connections and setup
the windows network securely instead?

Ben

Reply to this Message

JJ - 18 Sep 2007 17:02 GMT

Thanks for the reply, unfortunately because of the system design (which is
out of my control) I can't change the dB user's rights and/or take advantage
of windows authentication. I won't go into details, but basically those are
not options.

I've looked into SectionInformation.ProtectSection(), but that appears to be
for web.config file only? And really, encrypting the file is not my problem.

Let me re-phrase my question in a different way. If I encrypt my connection
info file, what is the best way to protect the decryption logic? I
understand that advanced users will be able to break down any scheme I come
up with, that's the nature of the game. However, I want, well must, protect
it to the upmost degree possible to satisfy the "higher ups". 8) Is
obfuscation my best bet?

> > First, I want to confess I am not security expert by any stretch of the
> > imagination, but I have been tasked with securing our dB connection
[quoted text clipped - 22 lines]
>
> Ben

Reply to this Message

Ben Schwehn - 18 Sep 2007 17:30 GMT

> I've looked into SectionInformation.ProtectSection(), but that appears to be
> for web.config file only?

Works for winforms just fine.

> Let me re-phrase my question in a different way. If I encrypt my connection
> info file, what is the best way to protect the decryption logic?

To my understanding, the reason why using
SectionInformation.ProtectSection() isn't such a a bad idea is, that you
can use DpapiProtectedConfigurationProvider which uses windows built in
cryptographic functions and you can configure it so that only a specific
windows account or windows machine is able to decrypt the file. Breaking
it is probably quite a bit harder then just using some custom encryption
scheme and storing the key to that somewhere.

But I'm no security expert myself, I might be talking nonsense here :)

Ben

Reply to this Message

Göran Andersson - 18 Sep 2007 18:48 GMT

> Thanks for the reply, unfortunately because of the system design (which is
> out of my control) I can't change the dB user's rights and/or take advantage
[quoted text clipped - 11 lines]
> it to the upmost degree possible to satisfy the "higher ups". 8) Is
> obfuscation my best bet?

Obfuscation is your only bet, as long as you store all the information
that is used to decrypt the information on the machine.

The only other alternative that I can think of, is prompting the user
for a password, and use that password to produce the key for the
decryption. That way the information would be stored in the brain of the
user instead of on the machine.

Signature

Göran Andersson
_____
http://www.guffa.com

Reply to this Message

JJ - 18 Sep 2007 19:58 GMT

Okay, thanks for the replies. I've talked it over with my collegues and
because this is an internal application and we're merely trying to stop from
storing clear text connection string information primarily and code hacking
secondarily we'll go with encrypting the config file and then obfuscating the
decrption logic. That should suffice for our setup. Thanks again for the
replies, greatly appreciated.

> Obfuscation is your only bet, as long as you store all the information
> that is used to decrypt the information on the machine.
[quoted text clipped - 3 lines]
> decryption. That way the information would be stored in the brain of the
> user instead of on the machine.

Reply to this Message

Ben - 19 Sep 2007 01:59 GMT

> Okay, thanks for the replies. I've talked it over with my collegues and
> because this is an internal application and we're merely trying to stop
> from storing clear text connection string information primarily and code
> hacking secondarily we'll go with encrypting the config file and then
> obfuscating the decrption logic.

I would not spend (waste) much time on that (i.e. I'd go with the most
simple solution that satisfies the boss). Your weakest link is not going
to be the decryption algorithm (so ofuscating is serves no purpose) but
the fact that all a mischievous user has to do to get the connection
string is to do a crash dump when a connection is open (or even just
hangs around in memory somewhere) and run strings on it. No debugger,
dissasembler or anything fancy required. Takes about 20 seconds to do.
Unless you do something about the connectionstring being stored in clear
in memory somehow. But since your DbConnection needs the Connection
string, this is going to be tricky.

Ben

Reply to this Message

cubaman - 19 Sep 2007 12:49 GMT

> > Okay, thanks for the replies. I've talked it over with my collegues and
> > because this is an internal application and we're merely trying to stop
[quoted text clipped - 14 lines]
>
> Ben

Well, you also can use SecureString class:
http://msdn2.microsoft.com/en-us/library/system.security.securestring(vs.80).aspx

and here is a good article about it:
http://community.bartdesmet.net/blogs/bart/archive/2006/03/31/3851.aspx

But, unfortunately, SqlConnection does not accept a SecureString as
parameter :( so, it's not valid in this case, at least without some
workaround ;)

Reply to this Message

Push in the right direction on security...

Free Magazines