Re: UserNameTokens + Password.SendNone Implimentation

From: James Han*** (~jamie_at_darwinconsulting.com)
Date: 02/23/05

  • Next message: Keenan Newton: "Re: WS-Security" 
    Date: Wed, 23 Feb 2005 13:30:48 -0500

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

    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
    > 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 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
    > 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!

    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?

  • Next message: Keenan Newton: "Re: WS-Security"