Jonas Sicking wrote:
John Panzer wrote:
Jonas Sicking wrote:
John Panzer wrote:
Some comments on blocking of authentication credentials:
When making a cross-site access request
<http://dev.w3.org/2006/waf/access-control/#cross-site-access-request>,
user agents /should/ ensure to:
"Not allow the author to set cookies or authentication credentials
for the request, as this would allow for a distributed cookie or
credentials search."
and
Why can cookies and authentication information /not/ be provided by
the script author for the request?
This would allow dictionary based, distributed, cookies / user
credentials search.
There are schemes for Authorization: which do not use passwords and
therefore do not have a dictionary attack problem; one of them is
OAuth (http://oauth.net). It uses the Authorization: header by
preference and can be used within a browser. (OpenSocial is in fact
currently relying on OAuth for authorization of proxied cross-site
requests.)
Is the intent to block the use of Authorization: headers completely,
or only the use of Authorization: Basic and the like? If the
former, I suggest that hindering the use of newer, more secure
mechanisms for authentication reduces security rather than enhancing
it.
Authorization headers are still sent. However only the authentication
credentials that the user has already used to log into the site is sent.
That's the problem. One of the major reasons for OAuth is to allow
delegated authorization (I authorize site X to access my data on site
Y). Javascript code to do the mechanics already exists
(http://oauth.googlecode.com/svn/code/javascript/v2/) and could be
used on a page of site Y, if the page is allowed to access site X at
all. I don't think anyone expects built-in browser support for OAuth
or other schemes, but the current proposal actually hinders use of
these schemes by Javascript.
I quick look at OAuth and it looks like authentication is simply done
using the body of HTTP messages (primarily POST). Is that correct? If so
I don't see anything that should stop this from working with the spec
as-is. If this is wrong, could you please elaborate on what in the spec
makes OAuth impossible and how we could fix it.
My Misstake. I see that OAuth indeed uses the "Authorization" header.
Unfortunately I don't see a way we could allow setting that header
without also making it possible to perform directory based attacks. In
general it would be opening a can of worms to let you set this header
since there might be important user data in cookies, or maybe elsewhere.
So the server would get authorization data for one account, but cookie
data for another.
I guess we could add support for more negotiation between the client and
server to not just negotiate supported http-methods, but also support
other capabilities. However I'm very reluctant to add support for that
at this point and would rather see that in a version 2 of the spec.
/ Jonas
