Per, You may have a chance if you use a combination of methods but, as others have pointed out, once someone is logged in as admin, they pretty well own you.
I'll relate my solution as it may help out. I need a shared encryption key for one of my services (last week's thread). My solution, while not yet complete, looks something like this. I have a command line app that knows 1/3 of my key, and I pass another 1/3 into this app as a command line parameter (along with 1/2 of the entropy used for the DPAPI). The app encrypts the info using the DPAPI, and writes the data to the registry, along with the entropy. This command line app is not installed on the machine, but is run as part of the MSI. I'm sure the exe is laying around in a temp folder somewhere, and obviously someone could dismantle my MSI to get the exe, but at least it's not sitting in my app folder. My service has the other 1/3 of the key, and when needed it gets the entropy, and partial key from the registry and decrypts and reassembles the key. The weakness in this is that the entropy that can be used to decrypt my partial key is in the registry. What I am working through now, is protecting this piece of data. I am looking at the possibility of creating a user on the machine in code, and using ACL (System.Security.AccessControl) to protect the registry keys, or moving the info to a file, and protecting the file via ACL. My service would also run under this user. So someone would need to run as that user to get to the encrypted part of my key in the registry (and also use reflector to get the other portion of my key). Also if I can change users while the initial app is running, then I could use that user to encrypt the data with DPAPI as an added layer. I am also using SecureString variables to store the base64 keys while I am working with them to keep them from getting scattered around memory. The next step will be to add obfuscation to the equation to make all of these steps less obvious. This is definitely not an unbreakable solution, but it should provide enough protection to keep the casual hacker out. HTH, Rob -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Per Bolmstedt Sent: Friday, March 28, 2008 12:41 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Thread implementation issue On Fri, 28 Mar 2008 10:58:05 -0400, Peter Osucha <[EMAIL PROTECTED]> wrote: > In working on implementing the Producer/Consumer queue from comments > earlier this week, [...] Actually, there's no need for sleeping threads in a producer/consumer queue, so I'd say your Blinker is something else, like an old-school "polling" mechanism. Check this, for example: http://www.yoda.arachsys.com/csharp/threads/deadlocks.shtml I'd remove the sleeping from the code and work my way toward a more elegant producer/consumer solution, using the feedback you've gotten so far. =================================== This list is hosted by DevelopMentorR http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
