[security] Browser support once again - considerations
Boris Erdmann
boris.erdmann at googlemail.com
Fri May 11 14:59:16 UTC 2007
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
More information about the security
mailing list