Re: [#177] Realm required on challenges

many browsers I've seen don't require there to be a realm as part of the 
challenge.  Some versions of WinGate didn't supply one, and Basic still 
worked in all the major browsers we tested with.  I guess we didn't test 
Safari.

But this is for auth to a proxy.

When we added a realm, we couldn't find anywhere which specified how a 
proxy should specify a realm of the entire universe.  In the end we used 
realm="/"

A lot of docs on the web which "explain" the realm parameter and how to 
set it, tell you to set it to any text that describes the abstract 
concept of the space within which the credentials are usable.  E.g. a 
quick google search shows sites with examples like:

"Secure Area"
"Our Site"
"My website"
"Test Authentication System"
etc

 This is nothing like a sitename, or anything the browser can use to 
judge whether or not the credentials are usable or not for another 
request.  So the browser has to simply assume the actual usability space 
of the credentials are defined by host, port, etc etc.  Surely this 
isn't the intent of realm?

Is one intent of realm to provide information to browsers so that they 
don't automatically re-submit credentials outside the realm (thereby 
potentially leaking sensitive information)?  How should a browser do 
that when it gets "Our Site"?

What happens when more than one site choose the same parameter for realm 
(e.g. read the same example web page).  Will the browser automatically 
submit Basic credentials to the second site based on the first site?

It seems the only safe thing for a browser to do is to not automatically 
resubmit any Basic credentials if any of port, server, protocol change 
regardless of whether they get a challenge with a matching realm to one 
previously seen.

IOW isn't the realm completely redundant?  Or worse?

Adrien

Jim Luther wrote:
> On Jul 7, 2009, at 1:28 AM, Adrien de Croy wrote:
>
>> I've never seen a browser use the realm for anything other than a 
>> label in a dialog box either.
>
> Apple's network framework code won't use a user's stored credentials 
> in a response unless the protection space for the authentication 
> challenge and the protection space for the stored credential match. 
> Our code considers protection spaces to match if the host, port 
> number, server type (http, https, http proxy, https proxy, ftp, etc), 
> and authentication scheme (Basic, Digest, etc) all match. If the 
> challenge includes a realm, then the stored credential's protection 
> space must have a realm and it must match the challenge's realm; if 
> there is no realm in the challenge, then the stored credential's 
> protection space must not have a realm. So yes, our code checks the 
> realm if it is included in a challenge and it require a realm for 
> Basic and Digest Access authentication.
>
> On Jul 7, 2009, at 2:00 AM, Thomas Broyer wrote:
>
>> See http://ltgt.net/tests/http-auth-realm/
>>
>> I tested it in IE8, Firefox 3.5, Opera 9.64, Safari 4 and Chrome
>> 3.0.191.3 (Dev channel), all on Windows.
>
> And you'll see that Safari 3 and 4 on Mac OS X, and Safari 3 on 
> Windows, also behave correctly.
>
> I've had complaints that our matching is too strict, but I don't think 
> so. For example, I've been told that other browsers will hand out 
> credentials stored for port 80 to a challenge from the same host on 
> port 443 if the rest of the challenge is the same -- I consider doing 
> that a security hole. Anyone want to write a test to check that?
>
> - Jim
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 7 July 2009 22:00:04 UTC