Replay attacks vs man in the middle
mart at degeneration.co.uk
Fri May 20 06:20:53 PDT 2005
Imran Ghory wrote:
> On 5/20/05, Sam Ruby <rubys at intertwingly.net> wrote:
>>Having a server issue a something unique to include in the data to be
>>signed addresses replay attacks. As long as it is extremely unlikely
>>that the server will issue the same data again, the knowledge that the
>>listener gains is effectively useless. This design could be improved by
>>having the server issue the openid.timestamp, and verify that the
>>timestamp returned was the one that the server initially provided.
> I was about to post a message saying essentially the same thing,
> however using the timestamp id is a bad idea as an attacker could just
> launch a simultaneous attack and succeed. It is convention in
> cryptographic protocols to use a nonce in such situation, essentially
> a random number which is uninfluencable by external factors. That way
> you reduce the chance of attack significantly more.
> Also I believe the reason for including timestamp is to ensure
> freshness but there doesn't seem to be anything in the protocol which
> actually verified the date/time is recent ?
I've been thinking about posting something like this for a while, but
not really being a security weenie I thought it better to wait for one
to appear and use all the right words.
A "nonce" seems like the right approach, though I wonder at what point
it should be generated and by whom. From Sam's reply which I'm replying
in parallel to, it seems that the nonce would just replace the
timestamp. However, surely the nonce needs to be something specific to
that request which the *consumer* can validate?
I'm probably missing a step, because it normally takes me a few goes to
figure out all of the to-ing and fro-ing with these transactions. No
doubt I'll slap myself on the forehead as soon as someone points out
what I've missed! :)
More information about the yadis