Subject: Re: Microsoft to Strike IE URL Passwords

From: [email-masked]
Date: Thu, 05 Feb 2004 18:16:53 -0500

RFC2396 describes a generic URI scheme,
including 3.2. Authority Component, without
specific application.

Going back to HTML 4.01(as an example), it
permits at 2.1.3, Relative URIs. But, RFC2616
makes no allowance for Relative URI's.

And that is exactly what I am getting at in
my earlier message.  The protocol has nothing
to do with what is on the HTML page and what
a browser does with an element on the page.

The thought that I had in the last few days
was:

Is it not possible, when username@password is
encountered, to pop up the usual login dialog
box with the elements filled in? The dialog
box already shows the authentication domain.
This would require an explicit action on 
the part of the user and gives the user
notification that an authentication is 
being attempted and the host that the user
is going to.  

It is the *silent* bypassing of this dialog 
through the *interpretation* of username@password
that is causing it to be a difficulty in the 
case at hand. Popping up a dialog box is much
less draconian than ignoring username@password
altogether.

Since Monday, I have received correspondence from
a very large e-commerce payment system who are
concerned with this very problem.  I can tell by
from the email address used to receive the correspondence
that the inquiries did not result from my posting
here on the list, but rather were related to 
searching for a solution.  This company
is the number one ranked company in their payment
method. They know that the proposed change
will break their systems at the customer level.

They are not happy campers. They are not Paypal,
but of similar magnitude.  It has already been
mentioned that Paypal payment links will break.

Bob

Julian Reschke wrote:
> 
> [email-masked] wrote:
> 
> > ...
> > If the argument is that 3.2.2 prescribes the
> > semantics of the href attribute of the HTML <A>
> > tag, then there is a lot of broken HMTL code
> > out there because it quite common to use
> > either root relative, or relative URL's in
> > href attributes.  The fact that common browsers
> > know what to do about this would be due to
> > their interpretative abilities.  By extension,
> > username:password@ is also an interpretive
> > ability.
>  > ...
> 
> As a matter of fact, RFC2396 and the HTML spec describe what can go into
> an HTML href. The URL format used in HTTP messages is completely
> irrelevant here. And yes, of course relative URIs are allowed here.
> 
>  > ...
> 
> Julian
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

-- 

------------------------------------------------------------------
FREE DOWNLOADS

iis bandwidth protection -- http://coldlink.com/

iis password protection -- http://wanderware.com/

------------------------------------------------------------------

..

---

From: David Morris <[email-masked]>
Date: Thu, 5 Feb 2004 15:56:27 -0800 (PST)

> less draconian than ignoring username@password

Actually, the MS fix isn't for the silent bypass per se, it
is for the fact that MSIE hides the content of the URL after the %01
character.

In my mind, that makes it an invalid URL which should be rejected. Your
suggestion for popping a dialog seems like a good optional security
enhancement. Add a checkbox to not show the dialog again for the same
server....

Dave Morris

---

From: [email-masked]
Date: Fri, 06 Feb 2004 17:27:27 -0500

Dave,

The KB article that was published seems to deal with
username:password and %01 as two separate "problems"
that will be addressed by a single patch.  I very
much agree that %01 is a bug and should be fixed.

username:password is a client interface problem
that should be addressed by greater/more useful
notification to the user that this is happening.

I am proposing as an alternative:

1/ the filled in dialog box as described earlier

2/ username:[email-masked] be rendered
in the address bar as www.example.com, since it
is the prepended username:password in the form
of a legitimate host name that is confusing
users.

3/ links just not be clickable in mail clients,
or at least mail clients should default to
operating in offline mode after retrieving
messages.  this also prevents such things
as image bugs that indicate a valid email
address.

I also would note that even if username:password
is eliminated, the goal of misdirecting to a website
other than expected by the user can be achieved
easily using a javascript handler for an onclick
event which redirects to a website by ip address.

Please note that:

1/ most users do not know how to relate an ip address
to a host name, nor do they care.

2/ the onclick does not even have to appear in the
href as it can be set by javascript itself

3/ the javascript handler can further cause the
browser window to open without an address bar
at all

So, eliminating username:password will gain 
nothing in terms of eliminating misdirection
of naive users.  It would take miscreants very
little time to figure out another way to do it.

It would actually be better to have a setting
in IE that offers as an install default:

"disallow ip address as hostname"

And yes, I know that the later versions of
Outlook Express operate by default in the
restricted security zone.

My hope is that someone from Microsoft reading
this list will take note of these suggestions.

Best Regards,

Bob

-- 

..