[security] Browser support once again - considerations

[Alaric Dailey]

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: security-bounces at openid.net [mailto:security-bounces at openid.net] On
Behalf Of Boris Erdmann
Sent: Friday, May 11, 2007 09:59
To: security at openid.net
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
security at openid.net
http://openid.net/mailman/listinfo/security