Re: hashed password and UsernameTokenManager



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]" <stcheng@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:o0$XGHPEGHA.1236@xxxxxxxxxxxxxxxxxxxxxxxx
> 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" <pcibraro@xxxxxxxxxxx>
> References: <Or4PeYGEGHA.1508@xxxxxxxxxxxxxxxxxxxx>
> 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$CZhCKEGHA.1028@xxxxxxxxxxxxxxxxxxxx>
> 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" <phil.lee@xxxxxxxxxxxxxxxxx> wrote in message
> news:Or4PeYGEGHA.1508@xxxxxxxxxxxxxxxxxxxxxxx
>> 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
>>
>
>
>


.



Relevant Pages

  • WSE 3.0 Running under default ASPNet user
    ... UsernameTokenManager which needs to access a remote database. ... service is set up in IIS to use anonymous access with a UserID and Password ... The web service needs to access a database on a remote server, ... UsernameTokenManager class) the database access is done via the ASPNET ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Trapping Soap Header Exceptions in UsernameToken Manager to close database connections
    ... AuthenticateTokento check a database and return a password string. ... fact that each web service method call opens and closes the connection ... string to the UsernameTokenManager which generates a Soap Header ...
    (microsoft.public.dotnet.framework.webservices.enhancements)

Loading