Re: hashed password and UsernameTokenManager

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/securusernametoken.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


"Sami Vaaraniemi" <samivanospam@xxxxxxxxxxxxxxx> wrote in message
news:OfRKzqpFGHA.3100@xxxxxxxxxxxxxxxxxxxxxxx
>
> "Steven Cheng[MSFT]" <stcheng@xxxxxxxxxxxxxxxxxxxx> wrote in message
> news:BERz8onEGHA.3764@xxxxxxxxxxxxxxxxxxxxxxxx
>> 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...
>
> 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
>
>>
>> Thanks,
>>
>> Steven Cheng
>> Microsoft Online Support
>
>


.

Relevant Pages

  • Re: hashed password and UsernameTokenManager
    ... Sami ... > The reason for further hashing and salting the already hashed password is ... > you have the database. ... >>> to also use hashed password text to construct the username token... ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Pathname to access and usernames in shortcut
    ... >> network drive (for maintenance reasons initially, ... >> using usernames but no passwords. ... change their passwords within the access database (they won't know how ... >> gets the current username from the system and then calls access (via the ...
    (microsoft.public.access.security)
  • Re: Getting NT User Login Names from Access 2000 or 2003
    ... time, i can recreate it in the blank database, per all your other thoughts. ... In the table setup and adding the bound SomeOtherField field to the ... >> form, plus binding the orig MyUserName field, defaulted to fOSUsername, to ... using the username field as ...
    (microsoft.public.access.formscoding)
  • Re: Login issues
    ... Depending on the computer or username, ... There is not way to enter to the database using ... If I enter as usual from my computer, the FM server automatically ... Perhaps someone changed your script, or the user name on your computer, or the default account in File Options. ...
    (comp.databases.filemaker)
  • Re: Getting NT User Login Names from Access 2000 or 2003
    ... It means a lot (as I need this func ... > form, plus binding the orig MyUserName field, defaulted to fOSUsername, to ... using the username field as ... You are performing this test on a completely *different* blank database, ...
    (microsoft.public.access.formscoding)
Loading