I have a .NET Windows Service that needs to store a secret on the machine and protect that secret from local system administrators. It is OK if domain admins have access.

This secret is not user entered. It is generated at installation time, and the installation can be automated.

My first thought was to use EFS. If I ran my Windows Service as a domain account and stored the secret in an EFS encrypted file, even local system administrators couldn't access the file unless they were also domain admins and utilized an EFS recovery certificate.

Is there a better option? Is there a way to do this without requiring the Windows Service run as a domain account?

  • 1
    This should never have been migrated because the solution is to use encryption, which means this needs to be done programmatically instead of trying to make it an OS level issue. – John Gardeniers Sep 14 '10 at 21:27
  • @John - agreed. What on earth does this have to do with anything server related? Voting to close as Belongs on SO – Mark Henderson Sep 14 '10 at 21:36
  • (for the naysayers when this gets back to SO, if the question was about EFS, then yes it could stay here, but the question is not about EFS, it's about appropriate techniques for storing a secret, of which EFS was offered as a possible solution, but the OP is asking for a better way than this) – Mark Henderson Sep 14 '10 at 21:38

I think using public key cryptography would be a good fit for this.

Generate the secret, then encrypt it with the public key. Save it locally. Share it everywhere for all anyone cares. Provided your initial encryption is good enough, there is no issue with local administrators having access to the encrypted secret.

This assumes of course you do not share the private key for the crypto with your local administrators :)

| improve this answer | |
  • OK, but where is your private key stored? – Gabe Jun 30 '14 at 20:10
  • To securely store a private key, I would use a cryptographic device, and not store it on the filesystem. For low security uses, filesystem can be good enough though. – Brennan Feb 17 '15 at 3:42
  • But how do you ensure that a local administrator can't access this cryptographic device (or file)? – Gabe Feb 17 '15 at 4:21
  • A crypto device with serious functionality e.g. FIPS 140-2 level 2 have its' own operating system, and separation of duties. These devices are commonly called hardware security modules (HSMs) with PCI, pciE, USB, and network based form factors, or in the lower end side, smartcard/microSD based versions. If you are storing it in software on the filesystem the administrator would have access. You may be successful in moving the crypto functionality to TPM type of modules on some newer motherboards, e.g. download.intel.com/support/motherboards/server/sb/… – Brennan Feb 17 '15 at 21:47

The registry is built for that. You can specify permissions at the key level.

| improve this answer | |
  • 1
    Local admins can run processes as SYSTEM, take ownership etc – Anders Sep 14 '10 at 19:59
  • The registry is also designed to ensure an admin, any admin, can obtain full access to it. – John Gardeniers Sep 14 '10 at 21:29
  • 1
    Admins can also take ownership of a local account. If you don't trust the folks who have physical access to your systems, you need to rethink your design. – duffbeer703 Sep 14 '10 at 21:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.