For those that are curious I'll try to shed a little more light on the why of this.
The scenario is actually fairly simple. An application where a given company will run multiple copies. Each instance the app needs to login to the same account (could be a share, a web service, etc.). There are too many users to reasonably grant each individual access to protected items. So, each app needs access to the password for the account. Fine, encrypt it. But then there needs to be a key to encrypt the password with. Each machine could randomly generate the key, which would help, but that makes deployment more complicated. Embedding the key in the assembly means that if it is extracted (not hard) then every customer is compromised. So customer specific keys are desired. It is therefore desirable to store the key as securely as possible. If I can find a windows application communication protocol that identifies the path of the calling exe then I can get fairly secure. 1. App makes call to service running as a user created for the purpose. 2. Service receives the call and creates a hash of the exe. 3. Hash is compared to a list of known good hash values. 4. If hash is good requested data retrieved via DPAPI and is returned. In this scenario attack vectors are: - Get admin access, change the service account's password and run an app to get the data from DPAPI. - De-compile the service, modify to reveal secret data, replace the strong-name key, re-start service. - Intercept the app-to-app message and man-in-the-middle it. - Acquire the key at whatever point it is initially provided to each machine. Not perfect but an improvement. Of course, this depends on a fictitious application communication protocol the provides the path of the caller. I haven't had time to search for this yet. .NET could go a long way to solving this problem. It already has strong-name keys. The CLR could provide a safe path from an app to DPAPI. Only an app with the same strong-name could access the data. The user would need to approve hand-off from one version of the app to another during upgrades. -Mont =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
