An excellent place to learn about this and various other security issues (including SSL vulnerabilities and problems with relying on DNS) are discussed at length at the anti-fraud mailing list.
http://lists.cacert.org/cgi-bin/mailman/listinfo/anti-fraud CAcert is lending their bandwidth, not necessarily expertise, to this list, there is tons of information to be had by searching the archives. Many people who have developed anti-phishing plugins already are (last time I checked) part of that list. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Boris Erdmann Sent: Friday, May 11, 2007 09:59 To: [email protected] Subject: [security] Browser support once again - considerations Hi list, i am currently implementing (trying to do so) a firefox extension to prevent phishing. Please direct me to somewhere else if there is a better place to discuss this. I would like to actively prevent a user from being trapped. In my mind this can only be achieved by a component from the browser chrome. My Idea is that upon focusing an openid_identifier (or friends) input field the browser should intercept user input by presenting a modal window, where the user has to enter their OpenID. The modal box would only disappear if it could detect everything ok: (This idea is borrowed from the cardspace modal desktop) Two strategies come to mind: A) Track the flow of the openid protocol. B) Check with the OP, if login is necessary, and if so, start login before submitting the openid to the consumer form. Well, both ways have their details: B) If I understand the specification right, it is perfectly "legal" to have an auth loop where neither javascript nor cookies are used. So it is perfectly valid, that the OP does "onetime" authentication, and that with every auth request from an RP the user has to revalidate with the OP (by interaction). In effect in this case there is no such thing as being logged in at the OP. Consequently a browser could not detect that state or even that a user just authenticated to an OP. So there can be no general solution using method B) ??? A) 1) Is it valid to present an OID input field to an already logged in user? (I would assume yes). If so, how would the browser know, that submission of the form would lead to a redirect to the OP? 2) If we ignore "special cases" like 1): OpenID 2.0 has made things a little bit more difficult. Indirect POST requests are now allowed in the auth loop. As such we wouldn't even expect 30x Answers from the consumer on form submission. Well I could detect a 200 response, and an OpenID transport form. But what if javascript is turned off for the web browser. Do we have to release the modal window and let the user press "OK"? Or would one expect the browser to implicitly submit such a form and possibly violate the law in several countries? Moreover, is it stated somewhere, that an auth loop has to be "continuous"?. That is: Is it valid to enter an OpenID at a consumer site, get directed through a set of pages, and only after a while be redirected to the OP for ID validation (I would assume yes, though I only searched for "continu" in the spec) Well, as it stands, I see little chances for a browser to track all variants of a valid OpenID flow. I mean, if the complexity of tracking is too high, chance are high, that protocol surveillance will be or get broken soon. Does the idea of a modal window have to die? Do I miss something here? -- Boris _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
