Microsoft To Remove Support For http(s) auth URLs

damohasi writes "According to Microsoft Knowledge Base, MS "plans to release a software update that removes support for handling user names and passwords in HTTP and HTTP with Secure Sockets Layer (SSL) or HTTPS URLs in Microsoft Internet Explorer". Whether this will break rfc 1738 or not, it might get webspace provider in trouble who offer @-domains like the German 1und1."

Comments

Alternate solutions

[jtheory]

I understand why they'd want to disable that format... but it is a standard, after all -- why not just pop up a warning showing the site you're really going to?

Re:Alternate solutions

[spitzak]

After reading all the comments here, I agree that MS's "solution" is bogus. A far better one would be:

1. Fix the status preview. But instead of showing the full path, show the actual URL with the usernae and password stripped, or show it with a leading '@'. This will hide the username/password from casual viewing, something a reply to this same comment said is a problem to his actual use of this scheme in browsers other than IE.

2. If the user clicks on such a link, pop up a box asking if the user really wants to do this. However a relative link (ie from one location with the same name&password to another) does not pop up the box.

3. To be really clever the box can also let the user choose a different name or password, prefilled with the URL values. Be careful to design it so a novice user is absolutely certain to cancel the box rather than hit ok.

Actually a bug fix for the IE spoofing problem

[joncarwash]

According to the Microsoft KB article itself, this is actually a fix for the IE spoofing problem reported in late 2003:

A malicious user could also use this URL syntax to create a hyperlink that appears to open a legitimate Web site but actually opens a deceptive (spoofed) Web site. For example, the following URL appears to open http://www.wingtiptoys.com but actually opens http://example.com: http://www.wingtiptoys.com@example.com

Despite the negative side-effect, this update is actually a fix for a large security issue in IE. Phishing has become a big problem recently, especially since Microsoft acknowledged the bug in IE. Now if users actually run the update, and then check to see the actual address to which they are giving information, phishing may not be as big of a problem.

Of Course...

[alexpage]

Because breaking standards compliance is a much better solution than fixing your fucking software in the first place!

There are several browsers which implement this feature without it being a security hole or risk. This is yet more evidence of Microsoft's inadequate attempts to provide a decent product, and yet more reason to advocate for unbundling IE - what incentive to M$ have to create a decent browser if their POS is installed on most desktops by default?

Then again, it's more reason for people to switch away to a proper web browser, so I guess it's not all bad news...

Re:first post

[DjReagan]

And you think its a reasonable work-around for an end user to be editing registry entries in order to get functionality that is specified in the RFCs?

ROFL

[Imperator]

This is hilarious. There's a bug in IE that's being exploited to steal credit card information. MS evidently hasn't figured out how to fix it so they'll remove support for a whole feature of HTTP.

I'm starting to see a pattern here. IE has standards-compliance issues and MS doesn't seem to be making any moves to increase standards support or support additional standards. The IE rendering engine hasn't really changed in years now and there aren't any plans on the horizon either. A bug that should be simple to fix hasn't been fixed in weeks (months?) and before they release a fix, they're releasing a workaround to one of the (several) problems that the bug is causing.

My conclusion? The IE code base is a mess. Like Netscape 4, it's grown too fast and with too little control from competent engineers. Forget things like proper CSS2 support: the IE team can't even wrestle the code to fix a simple bug. I wouldn't be surprised if MS has for some time now been in the process of rewriting IE (or substantial parts of it) from scratch. After all, it worked for the Mozilla Project.

Re:ROFL

[imr]

I think the situation is even worse than that:
they tied the browser to the os and now they cant fix the browser without breaking everything that is tied to it. And that means all software, not only redmond's, that is based upon those components.
Therefore, they can't apply one patch without tons of tests and that means time. So for a quick fix, they can't do anything but nerf the feature.
But don't worry, with .net and longhorn, things will get integrated even thighter into the os. Welcome to .netmare.

Meanwhile, having source code available and system and apps clearly separated under linux, it's just a matter of recompiling, fixing the eventual bug in the third party apps, and then the users just have to:
urpmi
apt get
yum
emerge
download the bunch of tgz
whatever their preference is, and everithing is upgraded at once.

Which reminds me of this work of this guy from cambridge who kinda proved that free software and proprietary's are equally secure bug wise, because after a certain amount of bugs, it takes the same time to find the next one. I bet he didnt include the bug fixing time in his equation. If you find the next bug at the same time but cant fix it for one month or are obliged to kill the features, because you can introduce new bugs outside your scope, I wouldnt say they are equally secure bug fixing wise..

More sensible solution

[Ianoo]

A far more sensible solution that I would propose is to do the following:

When a URL such as http://user:pass@www.domain/ is entered, display http://www.domain/ in the Address Bar and put "Logged in as user" in the status bar. This work just as well with https URLs, and would also give people a better sense of security since their passwords wouldn't be displayed in the address bar when viewing pages on an authenticated site.

It makes me wonder how much they are paying people to come up with solutions which involve breaking standards in the name of "security" when I can come up with a better idea in under 30 seconds...

Re:More sensible solution

[Phaid]

Agreed, but as Windows is generally targeted at people who don't do things like read status bar text, I'd go one further and, in addition to your solution, actually have a popup like...

"Security Warning"

"You are about to log in to site www.haxorheaven.com, with the following credentials:

username: microsoft.com
password: %blahfafafofo.

Click "OK" to proceed, "Cancel" to return to the previous page.

[OK] [Cancel]"

This would make it Really Obvious when someone is trying to misdirect users.

Re:Hell of a work around

[DukeyToo]

Of course it is possible to fix it properly. All other browsers do it just fine.

And of course it is a bug. It is a bug, because it is not the behavior that the programmers expected when they wrote the browser software.