From: Brian Candler <B.Candler@...>
Date: 2003-08-08T01:52:14+09:00
Subject: Re: More on DRB & OpenSSL

On Fri, Aug 08, 2003 at 01:11:16AM +0900, Hugh Sasse Staff Elec Eng wrote:
> > OK. That lets B authenticate A. The main weakness is that if the nonce and
> 
> So I have them both ways.
> 
> > response are sniffed, the password is subject to an off-line dictionary
> > attack.
> 
> Agreed.  I don't know a good way round this.  I expect any method
> based on Hashing has this misfeature.  SHA is said to be better than
> MD5 in the RFCs, small help though that is.

No, that's not it. It's not a weakness of the hash, it's a weakness of your
challenge-response protocol design. However it's fine as long as you choose
a strong password (say a true random 128 bit value) which cannot be
brute-forced.

Otherwise you go to a different system altogether - such as public key
authentication.

> > And of course, this exchange does not protect the rest of the data in
> > transit. An active attacker could allow this authentication exchange to take
> > place, and then substitute the subsequent session data with something else.
> 
> Which is why I keep changing the nonce for each bit of dialogue
> between the machines, try to ensure (Time(),Date()) that it never
> repeats, and make the plain text part of the input to the hasher, so
> its authenticity gets tested when the hash is checked.

Right, so you're saying that you calculate the hash over the payload *and*
the nonce:

        [ payload ] [nonce] [hash]
        ^^^^^^^^^^^^^^^^^^^
                              ^ Hash of (payload + nonce + secret)  

But once you've done that, you don't need the nonce in the first place,
which is the point I was trying to make before.

The nonce could still be useful to prevent replay attacks; that's where the
attacker simply resends a valid signed packet at a later time. But using a
nonce for that purpose requires that every packet is sent in response to a
challenge. A better mechanism is to use timestamps or sequence numbers on
your packets.

That's what the SecureMarshall class I posted did:

        [ payload ] [ expiry time ] [ hash ]
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                       ^ Hash of (payload + expiry + secret)

You can receive incoming packets asynchronously, and know that they are
valid within a given time window, without having to have a
challenge-response exchange and without having to keep track of which
nonces are "active" (awaiting a response) at any particular instant.

You still have the possibility of replay attack within the timestamp window.
It's horses for courses. The above mechanism works well for me - I can send
objects off to a completely untrusted person to return back to me at a later
stage (e.g. a subsequent POST of a HTML form), knowing that they have not
been tampered with.

Regards,

Brian.