RE: Microsoft to Strike IE URL Passwords

RFCs 2616 and 2396 (which updates 1738) are clear that username:password is
NOT legal in HTTP URLs.

>From 2616:

3.2.2 http URL

   The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

   If the port is empty or not given, port 80 is assumed. The semantics
   are that the identified resource is located at the server listening
   for TCP connections on that port of that host, and the Request-URI
   for the resource is abs_path (section 5.1.2). The use of IP addresses
   in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
   the abs_path is not present in the URL, it MUST be given as "/" when
   used as a Request-URI for a resource (section 5.1.2). If a proxy
   receives a host name which is not a fully qualified domain name, it
   MAY add its domain to the host name it received. If a proxy receives
   a fully qualified domain name, the proxy MUST NOT change the host
   name. 

> -----Original Message-----
> From: ietf-http-wg-request@w3.org 
> [mailto:ietf-http-wg-request@w3.org] On Behalf Of 
> wizard@newsreports.org
> Sent: Friday, January 30, 2004 5:27 PM
> To: Michael Howard; ietf-http-wg-request@w3.org; HTTP Working 
> Group; Michael Howard
> Cc: Dave Kristol
> Subject: Re: Microsoft to Strike IE URL Passwords
> 
> 
> Michael,
> 
> Off the top of my head, so I may be totally off base :)
> 
> But, username:password@example.com is a valid uri in the http 
> protocol.  It follows, therefore, that it is a valid HREF 
> value in an <A> tag. If the browser then does something other 
> than is intended when the <A> tag is invoked, then it is 
> arguably non-compliant.
> 
> That is my argument in a nutshell.  Now, I could get all 
> scholarly and dig out all the references, but this would make 
> the argument much more obtuse and hard to follow. I would not 
> advance anything that I did not feel was supported in the 
> relevant RFC's.
> 
> Now, as a matter of practicality, IE is a Microsoft product 
> and Microsoft can do as it wishes.  Further, it can be argued 
> that this is not a common usage of a uri.  But, it *is* used 
> and useful.  To break it would be a shame.  Especially if the 
> shortcomings can be solved another way.
> 
> To reiterate, the two problems that are referenced fall into 
> the category of program bug, and rendering that is suitable 
> for the majority of users.  This is not a failing in the 
> usage of the particular uri format at all.
> 
> By kicking up a fuss as early as possible, I am hoping that 
> more consideration will be given to a non-intrusive fix that 
> will leave the intended functionality intact.
> 
> Best Regards,
> 
> Bob
> 
> 
> Michael Howard wrote:
> > 
> > The plan, and it may change, is to nix username:pwd@ in a 
> url. Correct 
> > me if I'm wrong, but this format is only valid for ftp, not http.
> > 
> > Cheers, Michael
> > 
> > [Writing Secure Code 2nd Edition]
> > http://www.microsoft.com/mspress/books/5957.asp
> > [Protect Your PC] http://www.microsoft.com/protect [Blog] 
> > http://blogs.msdn.com/michael_howard
> > 
> > -----Original Message-----
> > From: wizard@newsreports.org [mailto:wizard@newsreports.org]
> > Sent: Friday, January 30, 2004 1:35 PM
> > To: ietf-http-wg-request@w3.org; HTTP Working Group; Michael Howard
> > Cc: Dave Kristol
> > Subject: Re: Microsoft to Strike IE URL Passwords
> > 
> > Michael,
> > 
> > Is this not really a rendering problem?
> > 
> > This remark includes the "%01" problem, and user perception 
> that the 
> > leading part before the "@" is the web site.
> > 
> > The first is a problem internal to the browser, and should be fixed.
> > 
> > The second is a rendering problem, in
> > that many users do not know the difference.
> > Therefore, it is more useful to present the url to the user without 
> > the credentials portion.
> > 
> > If the embedded credentials are permitted in a valid url, 
> and that url 
> > is embedded as, for example, the href of an <a> tag, and 
> the browser 
> > does not retrieve the referenced resource, then the browser 
> is broken.
> > 
> > Removing this valid behaviour will, in some cases, break 
> many months 
> > of work. I am involved in one such case.
> > 
> > Bob
> > 
> > Michael Howard wrote:
> > >
> > > Only the form: 
> "http(s)://username:password@server/resource.ext"  is 
> > > being removed; basic auth is untouched.
> > >
> > > Cheers, Michael
> > >
> > > [Writing Secure Code 2nd Edition]
> > > http://www.microsoft.com/mspress/books/5957.asp
> > > [Protect Your PC] http://www.microsoft.com/protect [Blog] 
> > > http://blogs.msdn.com/michael_howard
> > >
> > > -----Original Message-----
> > > From: ietf-http-wg-request@w3.org 
> > > [mailto:ietf-http-wg-request@w3.org]
> > > On Behalf Of Dave Kristol
> > > Sent: Thursday, January 29, 2004 11:38 AM
> > > To: HTTP Working Group
> > > Subject: Microsoft to Strike IE URL Passwords
> > >
> > > <http://www.internetnews.com/dev-news/article.php/3305741>
> > >
> > > If I understand this article correctly, it sounds like MS IE will 
> > > remove support for Basic Authentication.  While we all agree that 
> > > cleartext passwords are evil, this sounds to me like it 
> will create 
> > > a major compatibility problem at sites that use Basic.  And note 
> > > that it
> > 
> > > covers Basic over SSL, too, where the passwords would *not* be
> > cleartext.
> > >
> > > Dave Kristol
> > 
> > --
> > 
> > ------------------------------------------------------------------
> > FREE DOWNLOADS
> > 
> > iis bandwidth protection -- http://coldlink.com/
> > 
> > iis password protection -- http://wanderware.com/
> > 
> > ------------------------------------------------------------------
> > 
> > ..
> 
> -- 
> 
> 
> ------------------------------------------------------------------
> FREE DOWNLOADS
> 
> iis bandwidth protection -- http://coldlink.com/
> 
> iis password protection -- http://wanderware.com/
> 
> ------------------------------------------------------------------
> 
> 
> 
> 
> ..
> 
>