Sending a password to a Windows Service

Question

What is the best way to send a password to a Windows Service? Our application needs a password in order to start. I don't care that services are "normally" supposed to run without user interaction. Its good enough for us that an operator can start the application and then log off.

On a unix system, I would just echo the password over stdin but the service has no stdin.

Currently, we use the DPAPI to just store the password using CryptProtectData. While this, works, it presents other problems that are beginning to become troublesome.

I'm guessing that I'll need to use some form of IPC between the service and the application that is sending the password but I'm not sure which method is appropriate, if any.

Thanks

Answer 1

Two main options:

You could listen on a socket on startup and wait for the required password to be supplied (maybe embed an SSH server in there, so that the password cannot be snooped over the wire)

My preferred option would be to read the password from a configuration file (that can be secured to the minimum readership) or registry setting (again, sufficiently secure such that only your service and administrators can read/change it)

Answer 2

Thanks for responding Rowland.

You could listen on a socket on startup and wait for the required password to be supplied (maybe embed an SSH server in there, so that the password cannot be snooped over the wire)

I considered that but without certificate verification, wouldn't that leave us open to a man in the middle attack?

My preferred option would be to read the password from a configuration file (that can be secured to the minimum readership) or registry setting (again, sufficiently secure such that only your service and administrators can read/change it)

We're trying to follow "defense in depth" as much as possible such that if an attacker compromised the machine, he would not able to access our application.

Answer 3

You can use kerberos mutual authentication. There are few options and examples there.

But just wondering. On a compromised machine, There may be a key logger. So typing the password is never secure if you want to maintain security in this environment. The same problem exist afaik for unix terminals.

Answer 4

DPAPI in UserMode is really the best option, and storing the encrypted data in a protected location, e.g. registry key with limited ACL.
What exactly were the problems that are beginning to be troublesome? Maybe we can just solve those...

Answer 5

What exactly were the problems that are beginning to be troublesome? Maybe we can just solve those...

Currently, the application runs as the Local System account.

Our application stores a number of credentials in an encrypted file and uses the DPAPI (in UserMode) for the encryption.

Thus, when the application is installed, the installer is run as the Local System account. We also have a set of tools that ship with the application, some of which need access to this encrypted file and thus, they too need to run as the Local System account.

By the time the application is installed and started, we're heavily dependent on that account.

We're running into problems because one of our users wants to use the application to access a shared network drive. The Local System account has no such privileges and we can't simply run our service as a different user because our encrypted information is protected under the Local System Account.

We've tried to avoid the process of setting up a user account just for our application because it is installed across many different customers and environments, all of whom have wildly different security policies.

Answer 6

You can access a remote drive from a service running under system account. However, you will need to have credentials & share information to connect to the remote machine. You can use the API wnetaddconnection to gain access. Probably your encrypted file can store this credential as well.