-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The site checks the session and also uses a unique session token.
You have to be logged onto the OpenID server in order for this to work. On Wed, 21 Mar 2007 19:09:13 +0000 [EMAIL PROTECTED] wrote: >> 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. -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wpwEAQECAAYFAkYBhO0ACgkQrR8fg3y/m1BGlAQAk9kND4cY7HcJLH+o9/ukFp9hV1v/ qYuL79n1BNSDDWMYjQpY9qWB3Lvc1KqAAGESUYnvzPeNNGgKKCOIP+oPi4DHBcy+GrwG Et74N6G4p4UQ6GEbS4747lzbXXJklNgJQgabgzNiO1dFDBMwIwlMpS2KcgFdTtQ+IMTu AU6i9co= =J+64 -----END PGP SIGNATURE----- -- Click to find great rates on life insurance, save big, shop here http://tagline.hushmail.com/fc/CAaCXv1QSYQdlVKDzE49AnrgfbvX7BCN/ _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
