I'm writing a distributed desktop application in vb.net. I have a security concern regard my connection string. My connection string is encrypted and stored in the registry. My question is can a hacker use a memory sniffer to get the connection string when it get decrypted?

mmm. Sure, why not? since you can access all memory, why can't he sniff it?...
you should probably add credentials into the database too.

HTH

Gonzalo

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from dparsons signature and he Took that from planoie's profile
================================================== =========
My programs achieved a new certification (can you say the same?):
WORKS ON MY MACHINE
http://www.codinghorror.com/blog/archives/000818.html
================================================== =========
I know that CVS was evil, and now i got the proof:
http://worsethanfailure.com/Articles...-Hate-You.aspx
================================================== =========

It would be tough.

If your enterprise is unsecure enough for someone to mount an attack like this, you have some big problems.

To decrypt this, the string will, one way or another, exist somewhere. But memory space is tought to get at if you are not part of what’s going on in that memory space, and the string would not last for very long.

Possibly, if you are really concerned about this, you can go to the trouble to allocate memory for this (thereby obtaining a handle to that memory), lock it down (using the handle), use it, specifically overwrite it, then release the memory. The plain text would only exist for a few milliseconds (if that long). Someone would have to be pretty good indeed to find that!

So everytime you wanted to use the credentials, you would go through that process again. If you don't mind the performance degradation that might result from that, that is one method you might use.

The reason I suggest that, rather than using a string, then changing the value of the string, is that strings are immutable. When you "change their value," in reality new space is allocated for the resultant string, which is then written to that location, and the old location is abandoned, without being erased. It is likely to be overwritten soon, but the fact is that it persists for some indeffinite period of time.

Thank you for the fast response. Are there examples for setting creditials on SQL 2005? How do big companies protect their connection strings? Even if they use an API to exchange data a hacker can just intercept the password and use it to get sensitive data. Thanks....

Big companies secure their resources my securing their network. Then if all personnel and processes within that security boundary are trusted, you have security.

Someone sniffing around the memory of various resources on the network is pretty rare.

Windows itself provides a layer of security, restricting access through the use of the ACL, and so on.

Also, a well designed database restricts access to only the required level. So one connection string might provide on SELECT privileges. That account cannot corrupt the data, because it has no authority to modify any data. Another login might only allow DELETE. Or even better, only allow access to a stored procedure that does the actual deleting, and which rejects (ignores) requests that would delete everything. That way, you need to know what's there before you can delete it. A stored procedure like that can disable itself after a certain number of bogus attempts. (It would incorporate only running if a particular value was found in a table, and upon a certain number of bogus attempts, change that particular value. No more operation until a DBA resets the value.)

Security is a multi-layer, multi-technology, integrated defense plan.

Brian,

Thanks for the detailed explanation. You definitely got me thinking about security issues. I wish I new this before I started programming. I guess it's never too late to go back and implement new security methods. Again, Thank you for your comments