W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1996

Proxy authentication -Reply

From: <jwilde@westpub.com>
Date: Wed, 10 Jul 1996 08:49:00 -0600
Message-Id: <s1e36ed0.023@westpub.com>
To: S.N.Brodie@ecs.soton.ac.uk, www-talk@w3.org
>According to this user, Netscape also suffers from this problem, but
>MS-IE doesn't.
Microsoft Internet Explorer has the ability to store passwords into
memory.  The user is probably using this so he doesn't get prompted.  I
think it needs to be IE 2.x and above.

>First question: Is the proxy wrong to send a 401 response when it is
>the
>proxy that requires the authentication?  (I think it is) 

The Cern Proxy was not designed with access control in mine, and it
isn't safe to use passwords with the proxy for certain reasons.  Fixing
this would be an addition to the HTTP protocol.  The way you're
supposed to authenticate the Cern proxy is by domain name or ip
protection:  eg.

Protection protname {
         Mask @(*.westpub.com, *.westlaw.com)
}

Protection protname {
        Mask @(163.231.*.*)
}

Hence,  
         it's not working because your proxy is set up tottally wrong.  The
Server response is correct in returning the 401 because it is just
forwarding your get requests and is acting as a server because of your
mishap in the protection scheme with the proxy.  This is not true for the
regular httpd server btw.

>Second question: Now I can't see any way that MS-IE can possibly
>know
>to send the authentication every time.  Is it resending purely based on
>the realm in the WWW-Authenticate directive?  If so, isn't this quite a
>large security problem, especially since the basic authentication
>scheme only uses BASE64 encoding?  

I have answered this above.  After recieveing a 401 from the server, IE
sends out the default password which is stored by the user.  And realm
is not the only directive when authenticating to http.  It is based on
something called canononical root which would be everything till the last
/ in a string.  hence

http://www.westpub.com/authenticate/to/me/

equals

http://www.westpub.com/authenticate/to/me/file.html

does not equal

http://www.westpub.com:80/authenticate/to/me/  or 
http://www.westpub.com/authenticate/to/

based on the server response.  if
http://www.westpub.com:80/authenticate/to/me/ 
was accessed and responded to authenticate to a realm the browser
has already authenticated to, then the browser has the smarts to try the
previously tried uid/passwd  or uid:passwd  which is in Base64
encoding.




Jeff Wilde
Systems Engineer
West Publishing Company
610 Opperman Drive
Eagan, MN 55123
Internet-> jeff.wilde@westpub.com
Received on Wednesday, 10 July 1996 09:51:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:19 GMT