<<< Date Index >>>     <<< Thread Index >>>

Re: MS to stop allowing passwords in URLs



Hello Andrew,

Wednesday, January 28, 2004, 2:54:00 PM, you wrote:

MA> I just read that Microsoft will stop allowing IDs and passwords to be
MA> embedded in URLs used by Internet Explorer. So you will no longer be
MA> able to use a URL like https://user:password@xxxxxxxxxxxxxxxx/

MA> See http://support.microsoft.com/default.aspx?scid=kb;en-us;834489

MA> Their reasoning is that this will mitigate status bar spoofing as has
MA> recently been discussed here and in other forums.

That  reasoning  is also in the KB article and the bug in this portion
of IE is obliquely acknowledged.

MA>  The article even goes
MA> so far as to admit that recent versions of IE show only the URL before
MA> the @ sign while older versions do not.

The  article  states  the  opposite.  It  states that earlier versions
displayed  the entire URL (including authentication parts) whereas IE6
conceals  the  authentication  portion  and displays starting with the
hostname.  This is, of course, excluding cases that use known flaws in
the URL parsing and is also unique to windows 2003.

MA> Apparently MS has decided that this RFC URL syntax is simply too
MA> dangerous to allow in their products. 

If you read the HTTP 1.1 specs closely (RFC 2616) you will find that a
HTTP URL does NOT include the username:password in the syntax.

RFC  1738  and  RFC 2396 specify the format of "generic" URL's but RFC
1738 specifically refers to RFC 2616 for the format of HTTP URL's.

RFC's  1738  and RFC 2396 both discourage the use of username:password
information in URLs as well.

That  said, I liked the ability to source-specify login information as
well.  I  think we may all be just a little shocked to see MS removing
functionality  in  the  interests  of  security.  I  wonder if this is
because they were unable to fix the %00 spoofing or had too many other
issues with this syntax.

Another  plus  is  that  this  change may see an upsurge in the use of
Mozilla, which still supports this syntax.

-- 
Best regards,
 Sam                            mailto:sschinke@xxxxxxxxxxxxx