dotnet web services enhancements: All,

I want to implement a custom UsernameTokenManager because I need to store
our user credentials in a SQL database. I understand how I do this but I have
one question.

I want to store a hashed version of the user's password along with a salt
value. When I authenticate the user I will take the password entered, process
it using the salt value, and then compare that to the value stored in the
database. However, if I understand things, when I override the
AuthenticateToken method I need to return the password and WSE will compare
that value against the value entered by the user. Since this entered value
was not processed using the salt value the two values will not be the same
and thus the user won't be authenticated.

Is it possible to make WSE process the entered password using the salt value?

Thanks!

The thing to remember is you need to return the *same pw in the Auth method
as that which the user entered into the UsernameToken at the sender side.
It does not matter what the pw is, it just needs to be the same as it can
then verify regardless of SendPlain or SendHashed, etc. So that means the
sender needs to know the salt. This means the client needs a way to get the
same salt. So that usually means another method call. And if that is clear
text, then you can grab the clear salt off the wire and use with a
dictionary attack. So that means you need to encrypt the salt, so that
means a pki or symetric key session... See where this is going? I don't
like pw hashes for this reason. You can see how to crack even SendHashed
pwds at my blog at:

http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!178.entry

A better way to go is to use encryption. Send the pw plain text, but
encrypt it first with server's public key. Add some random salt to
beginning and then remove X bytes of salt after decrypting at server. This
is just to prevent two users with same pwd encrypting to same value. If
your client side assembly is signed, you have the server's public key. If
not, then you need some other way to verify server key such as a server cert
or prior out-of-band method such as at install or encrypted into your
program. The other thing is why use another DB? Now you have all the
hashed pwds and salts that is easy to do an inside job with a dictionary
attack. You also have to manage it and come up with change pwd tools, etc.
Why not just use AD (or the SAM) and leverage the AD tools for help desk,
etc.? Then just send the pw encrypted and use Win32s LogonUser to verify
auth. The other thing is you probably want a shared key after
authentication anyway so you can encrypt and sign future messages.
SecurityContextTokens are great for this, you can auth and get shared key at
same time to use for rest of session. I blogged a solution with c# code on
getting SCTs without needing Certs and using soap.tcp at
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!268.entry
This salts the pw and username and encrypts/signs everything so no
information is gleened over the wire. Then all your server side methods
just verify that the message was signed with an authenticated SCT (the wse
will take care of decrypting data and verifiying signatures automatically).

--
William Stacey, MVP
http://mvp.support.microsoft.com

[quoted text, click to view]