Re: Custom UsernameTokenManager

From: William Stacey [MVP] (staceywREMOVE_at_mvps.org)
Date: 01/31/05 

Date: Mon, 31 Jan 2005 12:11:33 -0500

The thing to remember is you need to return the *same pw in the Auth method
as that which the user entered into the UsernameToken at the sender side.
It does not matter what the pw is, it just needs to be the same as it can
then verify regardless of SendPlain or SendHashed, etc. So that means the
sender needs to know the salt. This means the client needs a way to get the
same salt. So that usually means another method call. And if that is clear
text, then you can grab the clear salt off the wire and use with a
dictionary attack. So that means you need to encrypt the salt, so that
means a pki or symetric key session... See where this is going? I don't
like pw hashes for this reason. You can see how to crack even SendHashed
pwds at my blog at:

http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!178.entry

A better way to go is to use encryption. Send the pw plain text, but
encrypt it first with server's public key. Add some random salt to
beginning and then remove X bytes of salt after decrypting at server. This
is just to prevent two users with same pwd encrypting to same value. If
your client side assembly is signed, you have the server's public key. If
not, then you need some other way to verify server key such as a server cert
or prior out-of-band method such as at install or encrypted into your
program. The other thing is why use another DB? Now you have all the
hashed pwds and salts that is easy to do an inside job with a dictionary
attack. You also have to manage it and come up with change pwd tools, etc.
Why not just use AD (or the SAM) and leverage the AD tools for help desk,
etc.? Then just send the pw encrypted and use Win32s LogonUser to verify
auth. The other thing is you probably want a shared key after
authentication anyway so you can encrypt and sign future messages.
SecurityContextTokens are great for this, you can auth and get shared key at
same time to use for rest of session. I blogged a solution with c# code on
getting SCTs without needing Certs and using soap.tcp at
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!268.entry
This salts the pw and username and encrypts/signs everything so no
information is gleened over the wire. Then all your server side methods
just verify that the message was signed with an authenticated SCT (the wse
will take care of decrypting data and verifiying signatures automatically). 

-- 
William Stacey, MVP
http://mvp.support.microsoft.com
"Dan" <Dan@discussions.microsoft.com> wrote in message
news:AE487418-D923-4EEC-BE02-752FF61F3391@microsoft.com...
> All,
>
> I want to implement a custom UsernameTokenManager because I need to store
> our user credentials in a SQL database. I understand how I do this but I
have
> one question.
>
> I want to store a hashed version of the user's password along with a salt
> value. When I authenticate the user I will take the password entered,
process
> it using the salt value, and then compare that to the value stored in the
> database. However, if I understand things, when I override the
> AuthenticateToken method I need to return the password and WSE will
compare
> that value against the value entered by the user. Since this entered value
> was not processed using the salt value the two values will not be the same
> and thus the user won't be authenticated.
>
> Is it possible to make WSE process the entered password using the salt
value?
>
> Thanks!
>
> Dan

Relevant Pages

  • Verifying a User Password - calling crypt()
    ... I'm writing a function which is supposed to simply verify a username ... I recall that the encrypt function required a salt value ... I'm calling encrypt() with the user's password as the salt and I'm ...
    (comp.unix.programmer)
  • Re: Password storage facility exe - how safe is this idea?
    ... phrase of at least 15 characters and a passcode. ... A salt doesn't have to be secret, and should not be created by the user. ... Or, you could always call out to DPAPI, to encrypt the password data using ... they can't just change the pass-phrase in there and use the ...
    (microsoft.public.dotnet.security)
  • Re: Values to use for a salt?
    ... there are definitely situations where salt is not secret. ... Protection of each user's hash code becomes important to prevent ... The problem is that now you must map username to password hash ... The authentication process now looks like this: ...
    (SecProg)
  • Re: my KDF vs dictionary attacks
    ... When the OP wrote, "the salt has 1 requirement, it must encrypt into a 32 character string, no more and no less, this means that the salt has a minimum of 5 digits and a maximum of 20 digits," did you understand what ... DES is a 64-bit block cipher - 8 bytes at a time. ...
    (sci.crypt)
  • Default AES Salt in ASPNET2 Site
    ... and uses custom AES and SHA1 keys ... in Web.config to encrypt or hash password information. ... The ManagedRinjdael approach uses both a key and a salt in its operation. ...
    (microsoft.public.dotnet.framework.aspnet)