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.

Best Regards,
Jonas Sicking

Reply via email to