> 2. The second problem is more serious you can create a specially > crafted web page to automatically log on to a web site and also add > that web site to the allow forever trusted site. The only > requirement is that you have to be logged onto the OpenID server.
This case I don't understand well. If the provider prevents replay attacks of trust dialogs with the user (e.g. nonce in form) and requires the request to come from the user agent with a valid session, how could a remote site establish such permanent trust? I would assume this is a bug in the OP, which is probably accepting a POST without any credentials other than a session cookie. Terry -----Original Message----- From: Paul C. Bryan <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [email protected] Sent: Wed, 21 Mar 2007 10:50 am Subject: Re: [security] MyOpenID On Wed, 2007-03-21 at 13:33 +0000, [EMAIL PROTECTED] wrote: > 1. First of all if you sign into a OpenID server in this case > (MyOpenID.com) then logon to an OpenID enabled site like > (http://ficlets.com/) then sign out of the OpenID enabled site. It > is possible to log them back onto the site from any remote web site. Presumably, this is true only: a) as long as I am still logged into the OpenID provider, b) the remote site knows the OpenID login URL of the client site. Correct? The risk here is that I would have a session with the client site without explicitly asking for it? > 2. The second problem is more serious you can create a specially > crafted web page to automatically log on to a web site and also add > that web site to the allow forever trusted site. The only > requirement is that you have to be logged onto the OpenID server. This case I don't understand well. If the provider prevents replay attacks of trust dialogs with the user (e.g. nonce in form) and requires the request to come from the user agent with a valid session, how could a remote site establish such permanent trust? > Both cases can be prevented if the OpenID specification requires > authorisation regardless of a cached token. I think the second case already requires authorization by the user. Properly developed providers should ask for the user to grant trust to the consumer site, and not be susceptible to crafted requests to bypass user dialog. Paul _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.
_______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
