Detecting the Man in the Middle
Nathan D. Bowen
nbowen+yadis at andtonic.com
Thu Jun 23 22:57:57 PDT 2005
Nathan D. Bowen wrote:
> a new thread to invite comment.
I've got some comments of my own, but I didn't want to pollute the
1) I am not a cryptographer, so hopefully Paul can provide guidance if
any of my assumptions about security are incorrect.
2) My experience has only been with one specific implementation, so
hopefully other developers can point out any hurdles they anticipate in
3) Brad just announced that some code will be rolling out soon, but I
don't know whether that means it's too late to consider this sort of
thing for now.
> A man-in-the-middle who impersonates the server from the standpoint of
> the consumer is probably not empowered to impersonate the server from
> the standpoint of all of the UAs who use that server.
It's not inconceivable that an attacker could compromised the entire
server site. I'd think of that attacker as more than a man in the
*middle*. I assume that complete compromise of the server is as far out
of OpenID's scope as is the physical security of the server's hardware
> So if the server somehow includes that DH public value in a response
> (or responses) that are sent through a non-compromised UA, the
> consumer can detect whether or not a man-in-the-middle was present
> during the initial DH association.
Just adding the association's dh_consumer_public as a new field to the
identity response would suffice. Other options would include adding an
SHA1 hash of the value instead, or adding one of those values to the
signature input instead of adding it as a new response field.
I expect this to be the sticky point for implementors, because it places
a new burden on the server, who now must remember the DH public value of
Perhaps the server could store the value only long enough to send it
with the first identity request for which it is relevant -- giving the
consumer a chance to detect an attack -- and then scrap it and free up
Of course, the consumer couldn't scrap the stored value after the first
UA it encounters, because that UA could be the man-in-the-middle -- but
the server is the party that might be saving memory by calculating
secrets instead of storing them. The consumer is already required to
store information about each association it makes.
As a side note, since any technique for detecting a man in the middle of
OpenID relies on subsequent requests from legitimate UAs, extremely
*short* expirations on associations might be as suspicious as extremely
More information about the yadis