[security] MyOpenID

[gaz_sec at hushmail.com]

-----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 thayes0993 at aol.com 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 at pbryan.net>
>To: gaz_sec at hushmail.com
>Cc: security at openid.net
>Sent: Wed, 21 Mar 2007 10:50 am
>Subject: Re: [security] MyOpenID
>
>
>
>On Wed, 2007-03-21 at 13:33 +0000, gaz_sec at hushmail.com 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
>security at openid.net 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/