UserNameTokens + Password.SendNone Implimentation

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

James Hancock - 17 Feb 2005 17:53 GMT

Ok, so I figured out what I was doing wrong with UserNameTokens. I know that
William's and SA's solution may be better, but it's just overkill for me. So
here's what I've done:

I pass the valid username, which allows our server to retrieve the password.

The client does not send the password that it already knows and is stored in
it's database in an encrypted way.

It generates the password by decrypting it from the database, and then
reencypting it, and then hasing it using SHA512. Thus creating a REALLY
strong password (yes, SHA1 is broken but irrelivent for the short
communications that we're doing.)

The server takes the username, looks it up in the database and returns from
the AuthenticateToken the password encrypted and hashed the same as the
client side.

We use Salamander's Protector so it's pretty much impossible to decompile
our code and find out what the encrypt/decrypt routines are, which are
specific to us, custom written by me. Of course they could go through the
compiled exe. and get this information from the assember code I guess, but
if they're along that far, you've got a bigger problem.

Our encrypt/decyrpt routines are time sensitive in this case so that two
runs will result in different encryption/decryption thus screwing the pouch
(within a margin of error for server time and client time of course)

The contents of the WebMethod params and attachments is also encrypted using
a different encryption mechanism so that even if you were to guess the
password in some really hard attack, you'd still be faced with more
encryption to deal with thus obviscating the result making it harder to do a
dictionary attack.

So I'm in effect creating a 512 bit strong password that is known by both
sides, which changes all of the time, and is never sent over the wire with
another level of encryption in the mix.

Can anyone see any issues with this? I can't, but I'm by no means a
cryptography expert.

Thanks,
James Hancock

Reply to this Message

William Stacey [MVP] - 17 Feb 2005 20:28 GMT

Let me see if I got this right:
1) You encrypt the password on the client side using some prior shared
secret? What algo (AES)? Just curious.
2) You take that result, add some time variant, and do a SHA256 hash on it
to give you password equiv (PE).
3) You create a UsernameToken with username, the PE, and SendNone.
4) You create a SoapEnvelope and add the UT.
5) You sign the soap body using the UT.

6) You have a custom UsernameTokenManager on the server and override the
AuthenticateToken(UsernameToken token) method.
7) You lookup the clear password and do 1 and 2 above and return the PE in
the AuthenticateToken method.
8) In the server soap method, you require an attached UT and that the body
was signed with the UT.
9) Do what ever in the method and return.

Is that about what your doing? If not, please update so we can be sure.
Cheers.

Signature

William Stacey, MVP
http://mvp.support.microsoft.com

> Ok, so I figured out what I was doing wrong with UserNameTokens. I know that
> William's and SA's solution may be better, but it's just overkill for me. So
[quoted text clipped - 39 lines]
> Thanks,
> James Hancock

Reply to this Message

James Hancock - 21 Feb 2005 16:02 GMT

> Let me see if I got this right:
> 1) You encrypt the password on the client side using some prior shared
> secret? What algo (AES)? Just curious.
> 2) You take that result, add some time variant, and do a SHA256 hash on it
> to give you password equiv (PE).

Actually SHA512, but yes.

> 3) You create a UsernameToken with username, the PE, and SendNone.
> 4) You create a SoapEnvelope and add the UT.
[quoted text clipped - 10 lines]
> Is that about what your doing? If not, please update so we can be sure.
> Cheers.

Yes, that's exactly what I'm doing. The password is a custom implimentaiton
of AES.

Seems to me like this should be safe and incredibly hard to crack. No?

Thanks!

James Hancock

Reply to this Message

William Stacey [MVP] - 22 Feb 2005 15:46 GMT

Actually, that seems pretty good James. It is basically what time factor
systems like RSA's SecureID do. Except with the HL devices, the secret is
stored in the device so you can't decompile the code or use a debugger to
see it. That is the one weakness in this system is that once the secret is
discovered, it is broke for all clients that use the same secret. And there
is no great way to store/hide that fixed secret. The best you can do is
obfuscate and encrypt the secret. However, once that is cracked, the whole
system is broke. Your also probably using the same secret in all client
packages unless your compiling a new program for each customer which could
be a major pain to manage. A new dynamic shared secret for each session
would be stronger, and all things considered, not much harder to implement
and you don't store "magic" anywhere. Also when using UT, you can't benefit
from DerivedKey tokens like you could with SCTs IIRC.

<Thinking to myself...> If you do store a fixed secret, I am not sure what
the AES step gives you here as you reduce it down to a 512 bit hash anyway.
So create some random long base64 string and store/encrypt that. Then hash
that together with your date string to give you the PE and could remove the
AES step. In either case, the PE could be dictionary attacked, but would
need to brute force 512 ~random bits in either case. In terms of
protecting the secret, the time string may be of questionable value as it is
not really unknown data. If I discover the format and how your mixing it
into the hash (say with code review, debugger, etc), I can pretty much gen
the same time string that the client does given my machine is within the
same minute. In effect, it becomes just some other ~known data I mix into
the hash. So I wonder if this just falls into the Security via Obscurity
category? It does, however, become kinda a variable salt. And if that is
the intent, could probably be done with a fixed len random salt to gain the
same effect and eliminate the time sync logic and drift issue. Thoughts
welcome?

> The password is a custom implimentaiton of AES.

Curious why use a custom AES implementation? Why not use the
RijndaelManaged class?

Question on time factor:
Are you grabing the current date time (UTC) and then rounding down to
current minute? Then on the server side doing the same? Unless I miss
something, it would seem both client and server have to be within the same
minute for this to work as with the UTM, you can only return one PW. If
that does not verify, you can't try minute before or minute after as WSE
would have already failed the auth. How are you approaching this to allow
some time drift? TIA!

Signature

William Stacey, MVP
http://mvp.support.microsoft.com

Reply to this Message

James Hancock - 23 Feb 2005 18:30 GMT

> Actually, that seems pretty good James. It is basically what time factor
> systems like RSA's SecureID do. Except with the HL devices, the secret is
[quoted text clipped - 13 lines]
> benefit
> from DerivedKey tokens like you could with SCTs IIRC.

The key is in the SQL Server databse encrypted. Persumably, the database is
in a secure location. If it isn't, then this whole conversation is pointless
because the database is already in their hands and the information that I'm
broadcasting is already compromised anyhow. The key is generated uniquely
when the software is registered with us and is specific to the company, so
only the company can be compromised and we have a tool to change it for the
entire company in one click if they have a laptop get stolen etc.

> <Thinking to myself...> If you do store a fixed secret, I am not sure
> what
[quoted text clipped - 19 lines]
> same effect and eliminate the time sync logic and drift issue. Thoughts
> welcome?

The idea using the AES encryption of the data is that if they decrypt the
first level of encryption, the whole thing is still encrypted so it makes
dictionary attacks harder. I realize that they'll see the formatting of the
XML message, but they won't get to the data. The AES is really an encrypted,
encrypted zip, so if they get around the AES they still have to be able to
recognize that the content of what they are decrypting is an encrypted zip
(not great, but hey) and recognize that they got a good dictionary decrypt.
(The content of the zip is an xml stream.) The benefit of using zip and zip
encryption was that the message parts (Datasets) were really bulky with huge
overhead in XML. So by compressing them by Zip from the stream we saved
about 80% of the bandwidth we had without it, and we get the added security.

This comes out of reading some books about dictionary attacks and my
understanding that the way brute force dictionary attacks work is by
comparing the result of the brute force decrypt against words in the
original message's language of choice. Otherwise they don't know if they get
a valid decryption because it's just jibberish that could be right or not.
(this is the basis for triple DES I believe)

>> The password is a custom implimentaiton of AES.
>
> Curious why use a custom AES implementation? Why not use the
> RijndaelManaged class?

We started with that, but I read some stuff about RijndaelManaged that I
didn't like, so I did a wrapper around AES and did some tweaks to it.

> Question on time factor:
> Are you grabing the current date time (UTC) and then rounding down to
[quoted text clipped - 4 lines]
> would have already failed the auth. How are you approaching this to allow
> some time drift? TIA!

I embed the client system's DateTime.UTC in the username to the millisecond
on every transaction. It then takes that and calculates the delta (drift)
and offsets. It allows a specific amount of offset. Anything more than that
offset will be bounced with an error that the client system's clock is not
set correctly. (Servers are all synced to nuclear time using a time server)

I thought about not passing the UTC but it made my encrypt/decrypt harder to
work and less reliable, whereas if I do it this way, I don't see that it can
help the man in the middle, or any other type of attack to know the time,
because they still have to know the process to decrypt it.

Make sense?

Reply to this Message

hoon - 21 Feb 2005 19:45 GMT

I do not think you can simplify the steps that Williams code goes through to
establish a security context token (without X509 certs). I used his code to
establish a SSL type connection (and to encrypt attachments also which go out
of band).

It seems as if your code is using a pre-established secret unlike what
Williams code does. That will be a definite problem. No ?

Reply to this Message

James Hancock - 21 Feb 2005 22:17 GMT

It's a shared secret key that never gets transmitted over the wire and
changes over time no matter what user is connected. And since it's double
encrypted it should make it harder to decrypt with a dictionary attack I
would think...

I mean is there any way that a man in the middle or other attack could get
the data without having to brute force it with one heck of a good computer
network?

I haven't been able to find one, anyone else?

My feeling on the subject is that it's as secure if not more so than WSE
1.0's shared secret functionality. Is there a reason why I'm wrong?

>I do not think you can simplify the steps that Williams code goes through
>to
[quoted text clipped - 61 lines]
>> Thanks,
>> James Hancock

Reply to this Message

hoon - 22 Feb 2005 17:33 GMT

I think you are as safe as can be. Thinking out loudly:

1. A shared secret on open lines is established by encrypting with the
public key of the specific server. This would prevent man in the middle
problem (such as Diffie-Hellman).
2. Your secret never goes on the open lines. Therefore the secret is being
established though other channels (that are not susceptable to evaesdropping,
or MTM, or replay..?). Secondly, that secret is changed over time (kinda
derived keys in WSE).
3. (Non-Security related) Not deviating too much from WSE so things down the
line become difficult to implement or change.

> It's a shared secret key that never gets transmitted over the wire and
> changes over time no matter what user is connected. And since it's double
[quoted text clipped - 75 lines]
> >> Thanks,
> >> James Hancock

Reply to this Message

UserNameTokens + Password.SendNone Implimentation

Free Magazines