How to securely store passwords in .NET applications?

  • Thread starter Thread starter Peter Rilling
  • Start date Start date
P

Peter Rilling

How does Windows store passwords that it uses? For instance, when you
install a service, you can provide it the username and password. This
information is stored somehow so that at a later date the service can start
without interaction from the user. Also for COM+ components.

This is what I want to be able to do. I want the ability to store passwords
in a protected manor so that my .NET application can start a secure process
at a later time. Maybe some built-in mechanism in Windows or some framework
classes?
 
Search for DPAPI (data protection API). Only available on XP though.

Another search you can do is Key Store. Some people have written managed key
stores or key stores that integrate with the older NT api. In any case, it's
also data protection used to store secrets (like encryption keys and
passwords).

-Rob [MVP]
 
Thanks.

I am using DP for some of my code so I am familiar with it. But I am not
sure if I can use it to secure my passwords.

Is this how Windows saves the passwords for a Windows services or COM+
component. From what I know about DP, it uses the credentials of the
current user as the key to the encryption/decryption of data. This is fine
if I want to limit the encrypted information to the current user.

Let's take an example of a Windows service (you know, the programs that can
automatically start when the machine boots). Suppose that I install a
service application. I give that application the username and password for
some account. That information is stored somewhere, I assume in some
secured format. Later that day, the machine starts up. Upon boot, the
service that I installed is launched. (At this point in time, there is no
user context, so I would image that this information is not stored using the
DP API.) The password is retrieved by Windows (whatever process controls
the launching of services) and what information is passed to the
LoginUser(...) where it then uses the returned ticket. The other
alternative would be to store information at the machine level, but then any
one with access to the machine and decrypt the information.

This is similar to what I would like to do. I want to encrypt some password
information. Store it. Then be able to use that information to call the
LoginUser(...) API function so that I can impersonate the current user when
my application requires certain resources. My application would be usable
by any account and my application should have access to a single username
and password that is defined by an administrator. This way, the application
can access these external resources by a single password, and that password
is secure so that none of the users to the system will be able to determine
what the is password and use it for other purposes.
 
Back
Top