Re: IE and cached passwords

1999-09-01 Thread Paul Leach (Exchange)

 -Original Message-
 From: Aleph One [mailto:[EMAIL PROTECTED]]
 Sent: Saturday, August 28, 1999 11:31 AM

 On Fri, Aug 27, 1999 at 07:04:53PM -0700, Paul Leach (Exchange) wrote:
  The server gets to say, in the WWW-Authenticate challenge
 header field, for which "realm" it wants credentials (name+password). If
both
 www.company.com and www.company.com:81 send the same realm, then the same
 password will continue to work.
 
  This behavior is as spec'd for HTTP Authentication, RFC 2617.
 
  So, it is not a security flaw.

 Paul,

   That is false. Quoting RFC2617, Page 3:
snip

Indeed. That'll teach me to rely on memory. Even if I was the last person to
modify those words when editing 2617.

I forwarded the bug report to the IE security team.

Paul



Re: IE and cached passwords

1999-08-29 Thread Peter W

On Fri, 27 Aug 1999, Paul Leach (Exchange) wrote:

 The server gets to say, in the WWW-Authenticate challenge header field, for
 which "realm" it wants credentials (name+password). If both www.company.com
 and www.company.com:81 send the same realm, then the same password will
 continue to work.

 This behavior is as spec'd for HTTP Authentication, RFC 2617.

Not the way I read the RFC's. The "realm" is supposed to apply to the
absoluteURI minus the URI path component, which means "example.com" and
"example.com:81" are different. Details follow.

Section 1.2 of RFC 2617:

   The realm directive (case-insensitive) is required for all
   authentication schemes that issue a challenge. The realm value
   (case-sensitive), in combination with the canonical root URL (the
   absoluteURI for the server whose abs_path is empty; see section 5.1.2
   of [RFC 2616]) of the server being accessed, defines the protection
   space.

Section 5.1.2 of RFC 2616 gives an example absoluteURI:

   The absoluteURI form is REQUIRED when the request is being made to a
   proxy.

...snip...

   An example Request-Line would be:

   GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

...snip... [and here the RFC clearly indicates what an abs_path is]

   The most common form of Request-URI is that used to identify a
   resource on an origin server or gateway. In this case the absolute
   path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
   the Request-URI, and the network location of the URI (authority) MUST
   be transmitted in a Host header field. For example, a client wishing
   to retrieve the resource above directly from the origin server would
   create a TCP connection to port 80 of the host "www.w3.org" and send
   the lines:

   GET /pub/WWW/TheProject.html HTTP/1.1
   Host: www.w3.org

So in the RFC 2616 example, "absoluteURI" is
"http://www.w3.org/pub/WWW/TheProject.html" and abs_path is
"/pub/WWW/TheProject.html". Applying the definition of "canonical root
URL" from the appropriate section of the RFC you cite, we get a canonical
root URL of "http://www.w3.org".

Naturally, if the w3.org Web server were running on a different port, our
"math" would look like:
http://www.example.org:81/pub/WWW/TheProject.html
  -  /pub/WWW/TheProject.html
  --
http://www.example.org:81
and the :81 would be part of the "authority" segment of the URI (as
described in section 3.2 of RFC 2396 and section 14.23 of RFC 2616;
discussion in section 3.2.2 of RFC 1945 [HTTP 1.0 spec] is similar).

-Peter

The Intel Pentium III chip: designed to deny your privacy
Boycott Intel. http://www.privacy.org/bigbrotherinside/