Re: [xhr] RFC2617 Digest authentication

  On 8/10/10 15:34 , Anne van Kesteren wrote:
> On Tue, 27 Jul 2010 16:32:48 +0200, Yrjänä Rankka 
> <ghard@openlinksw.com> wrote:
>> Please correct me if I'm wrong, but as I read the XHR level 2 draft, 
>> it seems impossible to do Digest auth with custom mechanism for 
>> acquiring the authentication credentials. I.e. supplying your own 
>> login dialog.
>>
>> To correctly digest authenticate, one needs to be challenged by the 
>> server first. To do that one needs to attempt to invoke a method on a 
>> resource without, or with invalid credentials. The resulting 401 
>> Unauthorized reply then contains the challenge with nonce, opaque, 
>> etc. values required to produce correct reply.
>>
>> In order to inhibit the browser from prompting the credentials from 
>> user, one must define user, password in call to open() method. My 
>> observations show this will produce a basic Authenticate: header in 
>> the request thus leaking the user/password out in the open even 
>> though the server might refuse Basic auth.
>
> I believe some of the browsers wait to be challenged first, actually. 
> That is what should happen per XMLHttpRequest.
>
>
Yep. Most seem to do this after all. I think what I was seeing was 
caused by the realm in question having previously presented a basic 
authenticate challenge only, and the browsers in question caching that info.

>> Many servers do and should refuse HTTP Basic auth over a 
>> non-encrypted connection. This is required by WebDAV [1], for example.
>>
>> Now it may be possible to trick some of the clients into Digest 
>> authentication without prompting the user by first calling open() 
>> with bogus user/password - then catching the 401 reply and on 
>> subsequent try call open() again with correct user/password values, 
>> hoping that the client cached the challenge. This would qualify as a 
>> hack, though, since AFAIK this behaviour is not prescribed by the Draft.
>>
>> I have no problem with rolling my own Digest authentication routines 
>> in the client but this would require a clean flag in the XHR to 
>> disable any attempt to do authentication on its behalf. Then again, 
>> another flag forcing the XHR to only authenticate when challenged, 
>> and then choose the strongest available method, as required by 
>> rfc2617 [2] would be preferable and would make it easier for 
>> developers to use a standard authentication method, reusing what's 
>> already implemented in most (modern) clients.
>
> We might add such a flag and a flag to control redirects in the 
> future, but not for now.
>
Was worth a try anyway. For sure people shouldn't try and roll their own 
(often snake-oil -based) auth lightly. Would be great to be able to 
direct client to refuse BASIC auth over non-TLS wire altogether, though.

Yrjänä
>
>> [1] http://www.webdav.org/specs/rfc4918.html#rfc.section.20.1
>> [2] http://tools.ietf.org/html/rfc2617#section-4.6
>
>


-- 
Yrjana Rankka            | ghard@openlinksw.com
Developer, Virtuoso Team | http://www.openlinksw.com
                          | Making Technology Work For You

Received on Tuesday, 10 August 2010 16:02:44 UTC