hashed password and UsernameTokenManager

hashed password and UsernameTokenManager

Post by Phil Le » Wed, 04 Jan 2006 22:03:38


Hi,

I'm using WSE3 username/password over certificate - I can implement my own
(test) UsernameTokenManager like this:

public class MyUsernameTokenManager : UsernameTokenManager
{
...

protected override string AuthenticateToken( UsernameToken token, string
authenticatedPassword )
{
// for clear text passwords
return token.Password; // This is just for test purposes


}
}

This works fine.

If however I want to send hashed passwords using PasswordOption.SendHashed,
what do I need to return from AuthenticateToken?
Returning token.PasswordDigest.ToString() doesn't work.

Regards
Phil Lee
 
 
 

hashed password and UsernameTokenManager

Post by Pablo Cibr » Thu, 05 Jan 2006 05:02:40

Hi Phil,
You have to return the original password. You will have to get it from
somewhere, e.g. a database.
WSE computes a hash with the password that you returns and then compares
that hash with the Usernametoken's hash.

Regards,
Pablo Cibraro
http://www.yqcomputer.com/
http://www.yqcomputer.com/

 
 
 

hashed password and UsernameTokenManager

Post by stchen » Thu, 05 Jan 2006 14:43:07

Hi Phil,

I agree with Pablo, the "AuthenticateToken" method of the custom
UsernameTokenManager require us to return the correct CLEAR TEXT
password... (so that the runtime will use it for sequential decrypting or
sigining....) So in other words, this is usually used when the account
database is a custom storage ( a relational database table....) or in xml
file.... And it's not usable for windows security authority since no
clear text password is available...

Please feel free to post here if there're anything else unclear.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
--------------------
From: "Pablo Cibraro" < XXXX@XXXXX.COM >
References: < XXXX@XXXXX.COM >
Subject: Re: hashed password and UsernameTokenManager
Date: Tue, 3 Jan 2006 17:02:40 -0300
Lines: 44
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
Message-ID: <O$ XXXX@XXXXX.COM >
Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements
NNTP-Posting-Host: 200.123.99.98
Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.webservices.enhancements:8027
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements

Hi Phil,
You have to return the original password. You will have to get it from
somewhere, e.g. a database.
WSE computes a hash with the password that you returns and then compares
that hash with the Usernametoken's hash.

Regards,
Pablo Cibraro
http://weblogs.asp.net/cibrax
http://www.lagash.com

"Phil Lee" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
own



{\rtf1\ansi\ansicpg936\deff0\deflang1033\deflangfe2052{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\lang2052\f0\fs20 Hi Phil,
\par
\par I agree with Pablo, the "AuthenticateToken" method of the custom UsernameTokenManager require us to return the correct CLEAR TEXT password... (so that the runtime will use it for sequential decrypting or sigining....) So in other words, this is usually used when the account database is a custom storage ( a relational database table....) or in xml file.... And it's not usable for windows security authority since no clear text password is available...
\par
\par Please feel free to post here if there're anything else unclear.
\par
\par Regards,
\par
\par Steven Cheng
\par Microsoft Online Support
\par
\par Get Secure! www.microsoft.com/security
\par (This posting is provided "AS IS", with no warranties, and confers no rights.)
\par \pard\li720 --------------------
\par From: "Pablo Cibraro" < XXXX@XXXXX.COM >
\par References: < XXXX@XXXXX.COM >
\par Subject: Re: hashed password and UsernameTokenManager
\par Date: Tue, 3 Jan 2006 17:02:40 -0300
\par Lines: 44
\par X-Priority: 3
\par X-MSMail-Priority: Normal
\par X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
\par X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
\par X-RFC2646: Format=Flowed; Response
\par Message-ID: <O$ XXXX@XXXXX.COM >
\par Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements
\par NNTP-Posting-Host: 200.123.99.98
\par Path: TK2M
 
 
 

hashed password and UsernameTokenManager

Post by Phil Le » Sat, 07 Jan 2006 00:00:34

teven,

isn't is best practice to store a password equivalent and not a clear text
password in the database?

I suppose I can just send a password marked as cleartext but it would have
actually been hashed on the client. I could then salt and hash again before
storing in the database. I'm using this article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/securusernametoken.asp
for inspiration.

Regards
Phil Lee

"Steven Cheng[MSFT]" < XXXX@XXXXX.COM > wrote in message
news:o0$ XXXX@XXXXX.COM ...


 
 
 

hashed password and UsernameTokenManager

Post by stchen » Sat, 07 Jan 2006 13:32:27

Thanks for your response Phil,

Yes, storing password hash is the best practice... However, the cleartext
mentioned here is just what the value which is used to construct the
UsernameToken at clientside... Because when it used usernametoken or
derived token to encrypte or sign the message, we'll need the original
cleartext value to construct the token key and decrypte the message....
Thus, if your custom security database stores only password hash, you need
to also use hashed password text to construct the username token...

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)


--------------------
From: "Phil Lee" < XXXX@XXXXX.COM >
References: < XXXX@XXXXX.COM >
<O$ XXXX@XXXXX.COM >
<o0$ XXXX@XXXXX.COM >
Subject: Re: hashed password and UsernameTokenManager
Date: Thu, 5 Jan 2006 15:00:34 -0000
Lines: 103
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: <OT$ XXXX@XXXXX.COM >
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!tk2msftngp13.phx.gbl
Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.webservices.enhancements:8051
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements

Steven,

isn't is best practice to store a password equivalent and not a clear text
password in the database?

I suppose I can just send a password marked as cleartext but it would have
actually been hashed on the client. I could then salt and hash again
before
storing in the database. I'm using this article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/
securusernametoken.asp
for inspiration.

Regards
Phil Lee

"Steven Cheng[MSFT]" < XXXX@XXXXX.COM > wrote in message
news:o0$ XXXX@XXXXX.COM ...



{\rtf1\ansi\ansicpg936\deff0\deflang1033\deflangfe2052{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\lang2052\f0\fs20 Thanks for your response Phil,
\par
\par Yes, storing password hash is the best practice... However, the cleartext mentioned here is just what the value which is used to construct the UsernameToken at clientside... Because when it used usernametoken or derived token to encrypte or sign the message, we'll need the original cleartext value to construct the token key and decrypte the message.... Thus, if your custom security database stores only password hash, you need to also use hashed password text to construct the username token...
\par
\par Thanks,
\par
\par Steven Cheng
\par Microsoft Online Support
\par
\par Get Secure! www.microsoft.com/security
\par (This posting is provided "AS IS", with no warranties, and confers no rights.)
\par
\par
\par \pard\li720 --------------------
\par From: "Phil Lee" < XXXX@XXXXX.COM >
\par References: < XXXX@XXXXX.COM > <O$ XXXX@XXXXX.COM > <o0$ XXXX@XXXXX.COM >
\par Subject: Re: hashed password and UsernameTokenManager
\par Date: Thu, 5 Jan 2006 15:00:34 -0000
\par Lines: 103
\par X-Priority: 3
\par X-MSMail-Priority: Normal
\par X-Newsreader: Microsoft Ou
 
 
 

hashed password and UsernameTokenManager

Post by Phil Le » Wed, 11 Jan 2006 22:47:57

teven,

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


"Steven Cheng[MSFT]" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


 
 
 

hashed password and UsernameTokenManager

Post by stchen » Thu, 12 Jan 2006 15:54:01

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

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)


--------------------
From: "Phil Lee" < XXXX@XXXXX.COM >
References: < XXXX@XXXXX.COM >
<O$ XXXX@XXXXX.COM >
<o0$ XXXX@XXXXX.COM >
<OT$ XXXX@XXXXX.COM >
< XXXX@XXXXX.COM >
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: <# XXXX@XXXXX.COM >
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


"Steven Cheng[MSFT]" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/



{\rtf1\ansi\ansicpg936\deff0\deflang1033\deflangfe2052{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\lang2052\f0\fs20 Thanks for your response Phil,
\par
\par 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....
\par
\par Regards,
\par
\par Steven Cheng
\par Microsoft Online Support
\par
\par Get Secure! www.microsoft.com/security
\par (This posting is provided "AS IS", with no warranties, and confers no rights.)
\par
\par
\par \pard\li720 --------------------
\par From: "Phil Lee" < XXXX@XXXXX.COM >
\par References: < XXXX@XXXXX.COM > <O$ XXXX@XXXXX.COM > <o0$ XXXX@XXXXX.COM > <OT$ XXXX
 
 
 

hashed password and UsernameTokenManager

Post by Sami Vaara » Thu, 12 Jan 2006 19:44:43


Note that if you hash the password in the client by giving the hashed
password to UsernameToken, then the hashed password *becomes the password*.
If you do this, then IMO it is pointless to store the password hash in the
database.

Regards,
Sami
 
 
 

hashed password and UsernameTokenManager

Post by Phil Le » Thu, 12 Jan 2006 20:58:46

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://www.yqcomputer.com/

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
 
 
 

hashed password and UsernameTokenManager

Post by Sami Vaara » Fri, 13 Jan 2006 00:44:24

Yes, I agree. It does give a level of protection as users tend to use the
same or similar passwords on multiple sites.

Regards,
Sami