Password hashing question...

[=?Utf-8?B?Sm9l?=]

I need to store a password for use later in my web app and
I would like to use FormsAuthentication.HashPasswordForStoringInConfig File.

The question is, once it's hashed and stored, do I need to
unhash it to pass to windows for authentication? Or can
I set something in Web.Config that will do that?

I haven't found any documentation that points me to what to do
next.

[Jon Skeet [C# MVP]]

Joe <Jo*@discussions.microsoft.comwrote:

I need to store a password for use later in my web app and
I would like to use FormsAuthentication.HashPasswordForStoringInConfig File.

The question is, once it's hashed and stored, do I need to
unhash it to pass to windows for authentication? Or can
I set something in Web.Config that will do that?

I haven't found any documentation that points me to what to do
next.

You can't "unhash". A hash is a one-way conversion. The point of
hashing is that you can store the hash with no security risk - you can
hash what the user provides later on, and if the hashes match, the
password is (at least very probably) correct.

Storing the password as a hash is no use if you need to be able to
provide the plaintext password to another application at another time,
however.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[=?Utf-8?B?Sm9l?=]

Jon,

Thanks for the reply. I should have remembered that hashing is one way.

So, is there anyway to securely store a password in memory? The way
the app is written, each time an action is performed a DirectoryEntry
is created and then the actions are performed (create/delete user, modify
group membership...).

We are using Forms Authentication and do not want to use Integrated Auth.

Thanks for the thoughts.

"Jon Skeet [C# MVP]" wrote:

Joe <Jo*@discussions.microsoft.comwrote:

I need to store a password for use later in my web app and
I would like to use FormsAuthentication.HashPasswordForStoringInConfig File.

The question is, once it's hashed and stored, do I need to
unhash it to pass to windows for authentication? Or can
I set something in Web.Config that will do that?

I haven't found any documentation that points me to what to do
next.

You can't "unhash". A hash is a one-way conversion. The point of
hashing is that you can store the hash with no security risk - you can
hash what the user provides later on, and if the hashes match, the
password is (at least very probably) correct.

Storing the password as a hash is no use if you need to be able to
provide the plaintext password to another application at another time,
however.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[=?Utf-8?B?WE9S?=]

Can I ask why you do not want to use Integrated Auth here - it would be
perfect.

[Christof Nordiek]

Hi Joe,

no, there is no way to to securly store date your program has to read. You
only can try to divide the information neede to restore the data.
E.g. if you encrypt the password, the programm will need the key to encrypt
it. A hacker, wich has acces to both, the encrypted passsword and the key,
can easy decrypt the password.
You also can try to obscure the way, the data is encrypted. But still, all
information for this will remain in the program plus some store, the program
has access to.

So, there are some ways, to make it more difficult to hack the password, but
not to make it impossible.

The question is, how much is it harder, to access all thoses stores than to
access only a part of them.

Christof

"Joe" <Jo*@discussions.microsoft.comschrieb im Newsbeitrag
news:74**********************************@microsof t.com...

Jon,

Thanks for the reply. I should have remembered that hashing is one way.

So, is there anyway to securely store a password in memory? The way
the app is written, each time an action is performed a DirectoryEntry
is created and then the actions are performed (create/delete user, modify
group membership...).

We are using Forms Authentication and do not want to use Integrated Auth.

Thanks for the thoughts.

"Jon Skeet [C# MVP]" wrote:

>Joe <Jo*@discussions.microsoft.comwrote:

I need to store a password for use later in my web app and
I would like to use
FormsAuthentication.HashPasswordForStoringInConfig File.

The question is, once it's hashed and stored, do I need to
unhash it to pass to windows for authentication? Or can
I set something in Web.Config that will do that?

I haven't found any documentation that points me to what to do
next.

You can't "unhash". A hash is a one-way conversion. The point of
hashing is that you can store the hash with no security risk - you can
hash what the user provides later on, and if the hashes match, the
password is (at least very probably) correct.

Storing the password as a hash is no use if you need to be able to
provide the plaintext password to another application at another time,
however.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Willy Denoyette [MVP]]

"Joe" <Jo*@discussions.microsoft.comwrote in message
news:74**********************************@microsof t.com...

Jon,

Thanks for the reply. I should have remembered that hashing is one way.

So, is there anyway to securely store a password in memory? The way
the app is written, each time an action is performed a DirectoryEntry
is created and then the actions are performed (create/delete user, modify
group membership...).

We are using Forms Authentication and do not want to use Integrated Auth.

Update actions performed on an AD require "Domain Admin" credentials, your clients,
connected over the internet, aren't (shouldn't be) Domain Admin's they shouldn't even have
access to the AD.
That means you should use different identities/credentials for the web access and the
resource access. So, first you'll have to "validate" the web client credentials against a
custom "Identity Store", and once the client is validated, you'll have to switch context to
access the directory. As "Identity Store" you can use a private LDAP, a DB store or the AD,
the choice highly depends on the number of clients and your security requirements.
Once the client is authenticated, you can access the AD using "explicit" credentials being
these of a domain admin, so you have to make sure they 1) are taken from a *safe* location,
2) they aren't kept in memory for a *long* period.
A much better option is to have your AD application code in a System.ComponentServices
derived class and registered as a "Server Type" application in the COM+ catalog. The COM+
application should run in a account having "domain admin" privileges.

Willy.