Replay attacks vs man in the middle

[Sam Ruby]

Disclaimer: I am not a security weanie, nor do I play one on TV.  But
based on what I know...

Replay attacks are where somebody is able to passively listen into
network traffic, and gather some data that enables them to later send a
message as if it were from you.

Man in the middle attacks are where somebody actively is able to
intercept and replace network traffic, with the recipient being unaware
of the change.

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.

Unfortunately, even this is not sufficient to prevent man in the middle
attacks.  All the man in the middle needs to do is be patient - allow
the traffic to flow normally until the one message which contains the
full DSA signature is sent, and intercept that one.

In general, the way to address man in the middle attacks involves either
generating a hash -- or outright encoding -- over the full message.  An 
example of such an approach can be found here:

   http://golem.ph.utexas.edu/~distler/blog/archives/000320.html

Also note that the verify operation is something that is delayed in 
Jacques's implementation.  This can be important from two perspectives: 
eliminating delays and handling temporary network connectivity issues.

Finally, let me point out that I recognize that it is quite likely that 
this project is not aiming for government auditable levels of security. 
  As such, I am not suggesting that this needs to address 
man-in-the-middle attacks.  I'd only suggest that some of the smaller 
changes above be considered, and otherwise the documentation be adjusted 
to avoid setting up false expectations.

- Sam Ruby