Re: [#177] Realm required on challenges

On Jul 7, 2009, at 3:02 PM, Adrien de Croy wrote:

>
> 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?
You could base your credential "cache" on realms AND server/port  
keys.  If a client is asking for foo.com:8888 with a realm of /bar,  
and then asks for foo.com:8888 /snafu you would not want to  
automatically use the cached credential.  Even a request for foo.com: 
443 with a realm of /bar differs, so no automatic application of  
cached credentials are safe.

>
> 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:23:55 UTC