Thanks for your response Phil,

I think your current implementation is good according to the custom
UsernameTokenmanager model. And as for the PasswordOptions.SendHashed, from
the WSE documentation, you can find that it just use SHA1 to hash the
password, which provide a buildin option for you to hash the password in
case that some application directly store original clear text password
(also let user input at client) in db....

Regards,

Steven Cheng
Microsoft Online Support

--------------------
From: "Phil Lee" <phil.lee@newsgroups.nospam>
References: <Or4PeYGEGHA.1508@TK2MSFTNGP15.phx.gbl>
<O$CZhCKEGHA.1028@TK2MSFTNGP11.phx.gbl>
<o0$XGHPEGHA.1236@TK2MSFTNGXA02.phx.gbl>
<OT$EIjgEGHA.3728@tk2msftngp13.phx.gbl>
<BERz8onEGHA.3764@TK2MSFTNGXA02.phx.gbl>
Subject: Re: hashed password and UsernameTokenManager
Date: Tue, 10 Jan 2006 13:47:57 -0000
Lines: 184
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2670
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-RFC2646: Format=Flowed; Original
Message-ID: <#JXp2xeFGHA.1032@TK2MSFTNGP11.phx.gbl>
Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements
NNTP-Posting-Host: host86-132-72-9.range86-132.btcentralplus.com 86.132.72.9
Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.webservices.enhancements:8085
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements

Steven,

this is what I have implemented:

Client:

   proxy.SetClientCredential( new UsernameToken( "name", "base 64 encoded
MD5 hashed password",  PasswordOptions.SendPlainText ) );

Server:

   string AuthenticateToken(UsernameToken token)
   {
       lookup salt and iteratively hashed salted password equivalent from
DB
       salt and iteratively hash token.Password

       if they match then return token.Password.
   }

But I am still confused as to the reason for having
PasswordOptions.SendHashed.

I will have to tell clients of the web service that it's good practice to
send a password equivalent and not the cleartext password, but I can't
force
them to.

Regards
Phil Lee

Sami,

As you say an MD5 hashed password in the UsernameToken is a password itself
(or password equivalent).

The reason for further hashing and salting the already hashed password is to
make offline dictionary attacks more difficult if someone manages to steal
the database.  See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/secu
rusernametoken.asp

There are dictionaries of pre-hashed common passwords available which means
discovering passwords from  non-salted password hashes is easy if you have
the database.  This is why salting and iterative hashing is used.

If someone has stolen your database why bother about them getting the
passwords?  Because people tend to use the same password on more than one
site, so you are preventing the hacker getting easy access to more sites.

The reason for hashing the password on the client is to provide a simple
level of protection if someone hacks inside your secure channel (which is
encrypted of course) and can get access to the unencrypted data.  If this
happens then your pretty stuffed though.

Phil