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.
John
