Results 1 to 5 of 5

Thread: need ideas on how to attack an Authentication and Encryption model I thought of

  1. #1
    Lord_Soth
    Guest

    need ideas on how to attack an Authentication and Encryption model I thought of

    hi guys,

    First let me start by saying that I am by far not a crypto guru. I just
    happened to get caught up in the need to secure a TCP session
    using both authentication and encryption, and I'm slowly studying
    the matter.
    The situation is as follows:

    There are two programs, one the client and the second is the server.
    These two tiers communicate using some protocol over TCP.
    The goal is to provide an authentication mechanism based on a
    password/passphrase, and then have the traffic between the two
    encrypted so that anyone sniffing it will not be able to figure it out.
    The idea is to not only secure the traffic, but making sure only the
    appropriate user can use the server (it is designed to be used by
    only one person at a time).
    So far, that is the problem, now to my idea, which I have no way
    of judging if is even secure.

    Let's take the assumption that the server knows the correct
    password. For the sake of argument, it is encrypted using MD5
    and stored locally on the server in some file.
    We'll also assume that when the TCP connection is established,
    the first command to the server should be of the following format:

    PASS <encrypted authentication string>

    Now, what I thought to do was that when the password is entered
    by a user, it is automatically hashed using MD5 (and thus, the
    entered password is not kept), and then sent to be the auth
    string, BUT, after having been encrypted ITSELF, so that no1
    can sniff it and try to brute force it.
    How to encrypt the pass ? Well, the first obvious thought I had
    was to use the hash itself to encrypt itself again, using XOR.
    When my brain switched on, I realized that anything XORed
    with itself becomes zeroes, so, no point there.
    The solution is to add another string to it, so that the password
    hash doesnt XOR with itself and give 0.
    A good string to add is for example a UTC time, which is just
    the seconds elapsed from epoch (in Unix).
    However, if any1 were to sniff this, he would know that the first
    octets are numbers, and have a pretty good estimate on the
    time (since he sniffs traffic that passes right after the time was
    taken from the OS). So if the padd time is for example 1000000,
    it would likely be 1000001 or something of the sorts when the
    traffic passes through the network. Knowing a few characters
    that you can XOR the traffic with will let you find a part of the
    hash, and that means reducing the number of possiblities left
    by a LOT
    So, after I realized THAT won't work as well, I tried to think of
    a way to padd the beginning of the hash with something that
    is NOT guessable.
    The idea is to take the password, add the time string to it, and
    use MD5 on that. What we get is a different hash, which we
    cannot guess in advance (we dont know the pword).
    We use say half of the chars from this new hash, we concatenate
    to that our password hash, and send that over the network,
    XOR encrypred with the password hash.

    so for example:

    password hash: e4uerhgergh1
    time+password hash: th894ht4er38

    we would send: th894h e4uerhgergh1 (without the space)

    XORed with e4uerhgergh1 (since the XORing hash is smaller in
    length, we will tile the XORing..).

    The server receives this, and knows that the first 6 chars should
    be dumped (we used 6 pads) and takes the rest and decrypts
    them using his stored password (but making sure to start from
    the 7th char of the hash).

    This is just the auth part, and the hash can be used for encryption
    later on.

    Now the attack ideas. Since the only way to check if a correct
    password has been entered is to initiate a connection, I see
    little possibility that any bruteforce can be done on this model.
    After all, if you cant try at least a few thousands of attempts per
    second, you really can't bruteforce...

    The big question is, are there any ways of cryptoanalysis that
    can somehow work on the encrypted info passed to the server?
    I mean, if the password is good, MD5 will give a good hash,
    and using the time+pass, you really do get a padding which cannot
    be guessed (or so I think hehe).


    Any guru here wanna comment on this model ? sugget ways
    to attack it ?
    It might not be THE way I choose to do this, since I'm hoping on
    using SSL or TLS, but still...

    Thanks in advance, and my apologies for the long message,
    Lord Soth
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #2
    Sab`
    Guest

    ?

    Hi Lord Soth,

    hopefully I did not misread your post but here are some attacks that come to mind right away.

    #1. Even though the time is hashed and concanted lets say
    strcat (*timehash, *passwordhash) . Given the person is sniffing he can still find a relation that the first 6 chars are just pseudo because the password hash will always be the same anyways.

    Suggestion: Take the time hash and scramble it using some maths with the second hash. Then have the time hash concatenated with that scrambled version. when the server recieves it have the server code take the first 6 chars and do the reverse scramble (Decryption) with those chars and get a resulting password hash.

    #2. Given they can sniff out this information in the first place means it will be insecure. Reason for this is the person can simply do a replay attack. Log what was sent to the server (the hash sent) and simply send that exact hash to the server and mimic your sends. Hence, pointless ruitine.

    Suggestion: Use public key setup and exchange block cipher keys which will then be used as the tunnel to exchange the password hash.

    Hopefully I did not misread what you wrote , good luck on your authentication system. -Sab
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  3. #3
    הבּרוּ נשׂאי כּלי יהוה mike's Avatar
    Join Date
    Mar 2001
    Posts
    491

    'Sab's suggestion

    Suggestion: Use public key setup and exchange block cipher keys which will then be used as the tunnel to exchange the password hash.
    This is what I'd suggest as well. Assuming the attacker can't do a man-in-the-middle attack, do a Diffie-Hellman key exchange. You could use a block cipher at this point to transmit the hash; another possibility is to send a MAC of the password. A MAC is a keyed hash; that is, you can't verify the hash unless you know the key. See Schneier for details or drop me a note.

  4. #4
    Lord_Soth
    Guest

    thanks for the pointers guys

    Schneier is definately on my next book list

    In fact, now I'm reading Scott Oaks' Java security (the client was
    written in java, by yours truly..).
    The other part is a linux daemon written in C, so, at the minimum
    I will have to read a book such as "Applied Cryptography".
    Anyways, if I run into more trouble, I'll be sure to drop you guys a
    note.

    Thanks in the meantime...

    LS
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  5. #5
    הבּרוּ נשׂאי כּלי יהוה mike's Avatar
    Join Date
    Mar 2001
    Posts
    491

    Applied Crypto

    You can find a pirated online copy here:

    h**p://www.geocities.com/condor60ro/document/0471128457/ewtoc.html

    According to section 18.4 on MACs, this construction using a hash function H and a key K is secure (comma means concatenate):

    H (K, H (K,M))

    You have to have some kind of random nonce to prevent replay attacks; I suggest generating a random key during the key exchange.
    Last edited by mike; March 14th, 2002 at 20:25.

Similar Threads

  1. Some of my crazy ideas...Not now...
    By tHE mUTABLE in forum Off Topic
    Replies: 9
    Last Post: February 14th, 2008, 13:52
  2. crypto thought crackme #6
    By mike in forum Mini Project Area
    Replies: 18
    Last Post: May 29th, 2006, 00:40
  3. New ideas for IDA
    By LLXX in forum Tools of Our Trade (TOT) Messageboard
    Replies: 2
    Last Post: May 1st, 2006, 06:34
  4. Any ideas for plugins?
    By 1bitshort in forum Plugins (General)
    Replies: 13
    Last Post: February 13th, 2006, 16:56
  5. A thought
    By Anonymous in forum OllyDbg Support Forums
    Replies: 1
    Last Post: July 5th, 2003, 11:09

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •