On Fri, 8 Aug 2003, Brian Candler wrote:

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

Yes, I see what you mean.  Well, it's not my design really, I
implemented what's in the RFCs cited earlier.  I wouldn't design my
own, I've learned that much! :-)

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

OK, I should look into that further, but isn't that subject to
similar attacks: not dictionary, but the parallel computer based
ones, like DES cracking challenges people set up.  Reply off list if
you wish, this could bore the legs of some readers and is getting
less Ruby specific! :-)

        [....]
>
> Right, so you're saying that you calculate the hash over the payload *and*
> the nonce:
>
>         [ payload ] [nonce] [hash]
>         ^^^^^^^^^^^^^^^^^^^
>                               ^ Hash of (payload + nonce + secret)

Yes....
>
> 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 gives timeout information, and prevents othere injecting
data into the system.  Even if they can forge something convincing
they need the right nonce to be able to do it NOW.
>
> The nonce could still be useful to prevent replay attacks; that's where the

That's the sort of thing I mean.

> 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

Agreed, unless the packet sent is a challenge in the other direction.

> challenge. A better mechanism is to use timestamps or sequence numbers on
> your packets.

But can't sequential numbers be forged easily?  (I use time as part
of the nonce, and time alone could be forged: people have had to put
security features into NTP to stop people attacking "time itself"
[There's a B movie in there somewhere!]).
>
> 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

That can be done with auth in the other direction, can't it?

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

That's it.  The point I've not been making clearly is that one can
provide a level of security and one may think it is good enough. But
there are always subtleties, and I think that it boils down to how
many subtleties one is prepared to consider.  The oft-cited thing
about "lines of code you don't write can't have bugs" suggests a
parallel: only messages you never have to send will be secure.
It sounds to me as though I may have things about right.  Though I
have still probably missed something! :-)

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

yes, hashes are particularly good for that.
>
> Regards,
>
> Brian.
>
>
        Thank you,
        Hugh