Re: UserNameToken with SendNone on Password

From: SA (informatica_at_freemail.nl)
Date: 02/15/05 

Date: Tue, 15 Feb 2005 11:31:32 -0600

> I would rather have all in one or the other myself. Or complete projects
in
> each if you wanted to show both.

I could have done that, however, I wrote the sample for myself in the first
place :o) I decided to share it because I think your idea is solid and
deserves attention.

> So why not just include them in your Utils class as static methods? That
is
> what I did, then I don't need another class for those simple methods.

No offense, but that code was written for my company and is therefore
intellectual property... I don't think it takes away from the usefulness of
the sample. That should be the principle behind component re-use, it's
black-box stuff.

> > * I use the machine key store to store the RSA key pair. A program is
> > included that will allow you to create an RSA key pair and store it in
the
> > machine key store.
>
> You can use the machine store, or *.snk file, or embedded string. The
> client only needs the public key. If you are using SN assems, then the
> public key in the Assembly is convient as you have the public key you know
> the server has a private key for. You can also embed the public key
string
> in the client so a simple sn -R will not work to do a MITM attack. On the
> server side, you could use key store or load from .snk.

OK, the goal for me is to have a way of distributing the software so that
every customer can have their own key pair, and (specific project
requirements) one client could connect to multiple servers from different
sites (with different key pairs in that case).

> > * I have split the SCTMessage class in 2: a request class and a response
> > class.
>
> I had thought about that originally, but any null values, by default,
don't
> serialize so the effect is the same if using one doc class and you can
drop
> another class. No value type fields, so we can pull this off kinda neat.
> If I had more fields and/or value type fields, I would probably go with
> another class as well.

I just think it's good design practice. They are in essence two different
documents and should therefore be treated as such.

> > * I include the length of the salt string in the request message.
>
> I wanted to include only that which was required or added security. I
don't
> see the salt length as adding security. The RSA recommendation is that it
> be random and >= 64 bits. So 8 or more bytes should do fine. Then just
> remove that many and you can drop another field from the protocol. The
salt
> is there to make it harder to do dictionary attacks on the username or
> password encrypted fields. To pull that off, you would need to guess or
> brute force the correct key, IV, salt, and password at the *same time. I
> just added it to the username field as it is cheap and pretty simple. And
> if you think about it. The username can be just as important to keep
secret
> as its plain text can be valuable information to an attacker.

I only include the length of the salt to make the whole scheme more
flexible, not for added security. Actually, I have wondered if adding the
salt length to the message might give the hacker to much info?

> > * In order to keep the code clean, I do not actually verify the
> > username/password against the windows database or any other credential
> > store. There is plenty of info available about those things, I don't see
> the
> > need to add another example.
>
> I might go ahead and include that logic for others as it is important to
the
> protocol. You should only return a SCT if you authenticate with correct
> username/password combo. So that integration is at heart of the solution.
> Your web methods should also require all soap bodies signed with a SCT.
> That is how you force a prior authentication and the other side has an
> *authenticated SCT. For example, your IsCustomerValid() web method should
> have the logic to require an authenticated SCT signed the soap body. As
it
> is, any client could call that method without including any token (unless
I
> missed something.) Cheers.

The code clearly indicates where the validation should take place.
Personally, I feel that adding any type of validation code would make the
sample specific to any chosen authentication method. Whether using Azman,
ADAM, windows logon methods, or some home-grown database implementation, the
idea is to authenticate the user.

I omitted the token validation from the sample, my mistake. One reason is
that I would really rather have a custom TokenIssuer so that WS-Policy can
then be used to validate incoming messages. I should not have distributed
the sample without that check though.

Relevant Pages

  • Custom UsernameTokenManager
    ... I want to implement a custom UsernameTokenManager because I need to store ... our user credentials in a SQL database. ... I want to store a hashed version of the user's password along with a salt ... When I authenticate the user I will take the password entered, ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Password checking theorical question
    ... This is IMHO the best way to store password tokens for future ... verification and requires no secret keys. ... B = Number of bits of salt to use ... - the Salt makes the space-complexity of a dictionary attack 2^B ...
    (sci.crypt)
  • Re: Hidden Application Data
    ... The reason I want to hide the user's credentials is not from the user ... If you must keep things locally then do not store the ... For a new application you should use SHA-256 as the hash. ... cryptographic salt seehttp://en.wikipedia.org/wiki/Salt_. ...
    (microsoft.public.dotnet.languages.csharp)
  • Confused by salt
    ... I hope someone can help clear my confusion. ... time back that used a hash function to store a password. ... advised me that I really ought to use a salt with this in order to add ...
    (sci.crypt)
  • Re: Validate User
    ... Validating a user is both checking the password, and ensuring the account is ... FormsAuthentication.Authenticate as if it passes the validation check then ... The username and password are correct. ... not but can't authenticate users that are not active. ...
    (microsoft.public.dotnet.framework.aspnet)