Wasn't the original point of this for FTP where username and password make more sense? I wonder if its still going to work for FTP. (I've never seen anyone actually use it for WEB).

I am not sure what the original point of it was but it was commonly used by the porn industry or at least by the porn hacker community.

I am pretty sure this form of the URL can be used when you know you need to get past BASIC authentication (i.e., without having to go through an authentication dialog). So, it is a useful form for web service type HTTP clients, but removing it from the browser human user interface doesn't seem like a huge loss.

Though, I don't know if there are other applications which programatically use the IE browser components that will break because of this change.

Don Wrote:

> I am not sure what the original point of it was

++++

Simple: to help out those people that did not like to retype in a popup screen its own password and to help out with scripts. Wget (commandline recursive web and ftp downloader) also support this. Ssh also supports the user@host form of authentication (not sure about the user:password@host...a test seems telling me user:pwd doesn't work under ssh).

I am laughing because IE is not fixing a security hole, but a social engiinering hole, which is in widespread use. I think that netscape and opera will follow up disabling username@password:website but giving you the possibility to enable it back (netscape has a fine password manager as well, not sure about opera).

Also many people pointed out that in some versions of the browser (IE) if you gave http://www.website.com@hackersite.com, the url bar only printed out http://www.website.com ...

Don Wrote:

> Well, micro-surgery wasn't invented yet so a surgery
> typically involved a lot of cutting and sawing.

++++

This Microsoft Fix is not micro-surgery either... it means that a great part of the web will have to switch their habits. Maybe they bookmarked their favourite website pages with the full user:pwd urls. More I think about it, the Fix seems to me more a way to avoid rewriting parts of the system (like for example: the IE history and cache...)

Because sensitive parts are hidden, storing username:password URLs as bookmarks is a security risk that requires adding additional UI dialogs for users to prevent people from exposing them when they share bookmarks.

Here's a question for the group at large: Given that the various RFC's that allow this syntax were written in a pre-virus, pre-security sensitive, pre-widescale usage (on the scale of the internet today as opposed to 15+ years ago) ... what would an expected timeframe be to produce another RFC (de novo or amended) that simply prevented this type of encoding of identifying information?

My own guess: 2 years minimum. And then, of course, there would be compliance issues, etc.

I personally have no sympathy for any website that encoded credentials in this manner (or encoded them in cookies in a similar manner -- I view this as equally egregious) and fails in the near future as a result of the change in IE. Imagine the customer service experience ... the phone rings (chat entry starts) at ACME WebService Providers helpdesk:

Helpdesk: Hello, ACME Web Hosting Hotline, how can I help you?

Customer: I can't access the site anymore. Why has this broken?
Helpdesk: It's Microsoft's fault.

Customer: Why?
Helpdesk: Well we valued both 1) you so little as a customer and 2) ourselves as a service provider that we encoded your username and password in plain-text so that any hacker could sniff it.

Customer: How is that Microsoft's fault?
Helpdesk: Well, they've broken our site by changing the behaviour of the browser. They don't care about you. They want you to have to remember your password. They want us to spend more money than necessary to protect your credentials.

;-(

It well past time that developers of the client and the server-side do everything possible to provide as much security as possible for the greater good. Even if the "spec" can't keep up.

100+ years ago in the pre-digital world, civil engineering, architectural standards, building codes, etc. came into being and evolved -- as needed and typically in response to tragic events that resulted in the loss of life and limb.

This "breaking of the RFC by IE" is but an example of the same process occuring in the digital world. It will happen again.

Phil wrote:
> This "breaking of the RFC by IE" is but an example of the
> same process occuring in the digital world.

++++

It wouldn't be "breaking of the RFC" if a consortium of companies, opensource groups, individuals and the IEEE sat down and rewrote RFCs in a sensitive, secure way. :)