W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2013

RE: Re: Fetch: HTTP authentication and CORS

From: HU, BIN <bh526r@att.com>
Date: Tue, 7 May 2013 00:23:32 +0000
To: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>, Jonas Sicking <jonas@sicking.cc>
CC: Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>, WebAppSec WG <public-webappsec@w3.org>
Message-ID: <179FD336116F754C876A9347238FE29A01025B1A@WABOTH9MSGUSR8L.ITServices.sbc.com>
If we are talking about RFC2617 HTTP Authentication, there are 2 authentication models:

(1) Basic Authentication model:

Under this circumstance, basically client can send the "username:password" pair at the "first" request, e.g. in the form:

https://username:password@www.example.com/path


which in turn maps to an HTTP header

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Where "username:password" is BASE64-encoded.

Because of the vulnerability of Basic Authentication model (without encryption), https is strongly recommended.

But in practice, Basic Authentication is rarely used, and it is mostly based on a challenge-response model, where the server challenges with 401 code, and a Authentication header to ask for Basic Authentication:

WWW-Authenticate: Basic realm="WallyWorld"

(2) Digest Authentication model:

Digest scheme is always based on challenge-response, and server challenges with 401 code, Authentication heade, and other important information such as nonce, e.g.:

         HTTP/1.1 401 Unauthorized
         WWW-Authenticate: Digest
                 realm="testrealm@host.com",
                 qop="auth,auth-int",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"

so that client can apply the appropriate digest algorithm, such as MD5, and generate the response:

         Authorization: Digest username="Mufasa",
                 realm="testrealm@host.com",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 uri="/dir/index.html",
                 qop=auth,
                 nc=00000001,
                 cnonce="0a4f113b",
                 response="6629fae49393a05397450978507c4ef1",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"

Because "nonce" is needed to generate the appropriate digest, the 401 challenge is required.

Hope it helps

Bin

-----Original Message-----
From: Hallvord Reiar Michaelsen Steen [mailto:hallvord@opera.com] 
Sent: Monday, May 06, 2013 11:13 AM
To: Jonas Sicking
Cc: Anne van Kesteren; WebApps WG; WebAppSec WG
Subject: Re: Re: Fetch: HTTP authentication and CORS


>> Here I don't agree anymore. If I want to retrieve a HTTP auth-protected resource
>> with XHR from a CORS-enabled server, the natural thing to do seems to try to pass
>> in the user name and password in the XHR open() call. If the script author supplied
>> user/pass and the server says 401 on a request without Authorization: surely the
>> natural next step is to re-try with Authorization:?
> 
> If the caller to the XHR.open() call provided a username and password,
> then shouldn't the implementation send that information in the *first*
> request rather than waiting for a 401?



I'd like to do that, but Anne thinks it violates the HTTP protocol (and apparently is hard to implement on top of certain networking libraries?).


Any networking devs who would like to comment on that?

-- 
Hallvord R. M. Steen
Core tester, Opera Software






Received on Tuesday, 7 May 2013 00:24:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:01 UTC