Re: hashed password and UsernameTokenManager


"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: HTTP proxy authentication using by SSPI
    ... I can't answer your question directly, but I will note that not even Windows ... at that point and instead uses the password hash. ... > authentication - I must know user's password and username. ... > password for authentication proccess, it takes it from some place. ...
    (microsoft.public.security)
  • Re: HTTP proxy authentication using by SSPI
    ... > at that point and instead uses the password hash. ... Windows domains store the password hash, ... >> authentication - I must know user's password and username. ... >> password for authentication proccess, it takes it from some place. ...
    (microsoft.public.security)