<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Let me answer than one....<br>
<br>
Josh Hoyt wrote:
<blockquote
cite="mid34714aad0610231341o50999ff0r62d9943155f4739@mail.gmail.com"
type="cite">
<pre wrap=""><!---->
After getting a little more information, I'm pretty certain that
myopenid.com has not allowed unauthorized access. </pre>
</blockquote>
Yes, it is most likely, that in fact this wasn't the case. Perhaps with
a little but more investment - and the fact, that myopenid.com operates
in http mode (i.e. unsecured) - we could have put the missing piece
together in order to allow it. Therefore as of now, I think, that the
myopenid authorization was spoofed, but not used at an RP and therefore
not succeeded. However I didn't checked this out and guess, it requires
just more time to do it actually...The myopnid site was obviously not
involved at all... <br>
<br>
However, this doesn't mean, that it wouldn't have been possible,
because of fact, the site speaks plain text and therefore my reasoning
to require https is still valid. The investment to succeed would have
been somewhat higher and perhaps more than the 15 minutes I invested in
it. A determined hacker would probable succeed with a little more
investment.<br>
<blockquote
cite="mid34714aad0610231341o50999ff0r62d9943155f4739@mail.gmail.com"
type="cite">
<pre wrap="">Note that
myopenid.com does not act as a relying party, so breaking the protocol
should not prevent a user from having to show their appropriate
credentials to access their myopenid.com accounts.
</pre>
</blockquote>
Now in the steps below, this is one of the options: DNS poisoning of
the RP would have done the trick or sniffing of the shared secret of
the real IDP would have been even easier, I guess...<br>
<blockquote
cite="mid34714aad0610231341o50999ff0r62d9943155f4739@mail.gmail.com"
type="cite">
<pre wrap="">
If I understand the attack:
1. Set up a target site to act as the rogue IdP and an identifier that
lists that IdP as authoritative.
3. Make name resolution *on the relying party* return the address of
the server with the compromised identifier.
4. Begin authentication on any user agent by entering the compromised
identifier into the login form on the IdP
5. Successfully redirect to the IdP and approve authentication
6. The relying party has accepted the compromised identifier without
contacting the *real* authoritative IdP.</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<div><font face="Arial" size="2">Regards</font></div>
<div><font face="Arial" size="2"> </font></div>
<div><font face="Arial" size="2">Signer: Eddy Nigg, StartCom Ltd.</font></div>
<div><font face="Arial" size="2">Phone: +1.213.341.0390</font></div>
</div>
</body>
</html>