Bugtraq mailing list archives
Re: MS to stop allowing passwords in URLs
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Wed, 04 Feb 2004 11:12:57 +1300
"McAllister, Andrew" <McAllisterA () umsystem edu> wrote:
I just read that Microsoft will stop allowing IDs and passwords to be embedded in URLs used by Internet Explorer. So you will no longer be able to use a URL like https://user:password () www somehost com/ See http://support.microsoft.com/default.aspx?scid=kb;en-us;834489
And a good thing too... You see, rather sadly, MS failed to note in that KB article that this change _finally_ makes IE's HTTP URL-handling more or less standards- conforming. How many years is that now since IE 3.0 introduced this non-standard behaviour?
Their reasoning is that this will mitigate status bar spoofing as has recently been discussed here and in other forums. The article even goes so far as to admit that recent versions of IE show only the URL before the @ sign while older versions do not. Apparently MS has decided that this RFC URL syntax is simply too dangerous to allow in their products.
It seems you misread the KB article and related RFCs. Admittedly the KB article seems to have been written be portray MS as the victim of harrassment by those nasty scammers, but in reality -- whatever MS' actual or professed reasons for making these changes -- MS has removed a _mis-feature_ that was not compliant with the agreed industry standards that IE is supposed to measure up against. Although that KB article refers the reader to RFC 2616 for further explanation, it also rather misleadingly refers to RFC 1738 and 2396. As RFC 2616 specifically covers the HTTP URL syntax in its section 3.2.2, the others are irrelevant to the issue of "What is the proper syntax of an HTTP URL?". RFC 2616 clearly _does not allow_ the "userid" component of the generic URI syntax _which is OPTIONAL _AND_ scheme dependent_. Go on, read all three RFCs and see for yourself...
Their suggested workarounds include among others: 1) Having users click the "Remember my password" checkbox in IE. 2) Using cookies. I personally use this syntax in only one production application, BBTray - a windows tray applet that watches my bigbrother monitoring server.
Then you should stop because it is not standards compliant. Do you really want to be part of the problem? (And a problem, that no matter it is not publicy admitting it is largely responsible for, MS itself is now trying to distance itself from?)
Click the applet and it opens a browser window with the id:passowrd () server com syntax. The ID and password is specific to our bigbrother application, my workstation sits behind two firewalls and I am the only admin on the box. So, I consider this use to be legit and relatively safe given the convenience it provides.
You're welcome to your opinion, but as a few moments reading the RFCs, rather than the documention of the devil-spawn of all browsers would have shown you way back when, it is a poor opinion.
I certainly don't consider the "remember my password" functionality nor stored cookies any more or less safe than this syntax.
Indeed, but at least they cooform to the standards that are supposed to make the WWW work and interoperate between dozens upon dozens of otherwise largely incompatible systems.
Anyone have any comments regarding legitimate uses of this syntax and
No, because there is no legitimate use of that syntax. If MS had implemented a scheme of its own -- say, "scamsRus" -- and allowed the userid component of the generic URI as a valid part of that scheme, then you would certainly be entitled to use a URL of the form: scamsRus://user:password () www somehost com/ but HTTP is defined without such support so you aren't entitled to use it as MS should not have supported it.
Microsoft removing it from their browser? (and presumably the OS since the browser IS the OS).
This is a good thing. The inconvenience to your relatively few users of their loss of this non-standard "feature" is worth the reduction in credible-seeming scams the removal of the feature will see in ensuing years. And perhaps MS removing this will pressure other browser developers to follow suit -- after all, who would want their product to be known as "the browser lagging IE in security features"? 8-) Regards, Nick FitzGerald
Current thread:
- Re: MS to stop allowing passwords in URLs, (continued)
- Re: MS to stop allowing passwords in URLs N407ER (Feb 03)
- Re: MS to stop allowing passwords in URLs Dave Warren (Feb 03)
- Re: MS to stop allowing passwords in URLs David B Harris (Feb 03)
- Re: MS to stop allowing passwords in URLs Östlund (Feb 04)
- Re: MS to stop allowing passwords in URLs Nick FitzGerald (Feb 06)
- Message not available
- Re: MS to stop allowing passwords in URLs Vinny Abello (Feb 03)
- Re: MS to stop allowing passwords in URLs Ansgar -59cobalt- Wiechers (Feb 03)
- RE: MS to stop allowing passwords in URLs Andrew Harwood (Feb 03)
- Re: MS to stop allowing passwords in URLs 3APA3A (Feb 03)
- Re: MS to stop allowing passwords in URLs Dave McCormick (Feb 03)
- Re: MS to stop allowing passwords in URLs Nick FitzGerald (Feb 03)
- Re: MS to stop allowing passwords in URLs Sam Schinke (Feb 03)
- Message not available
- Re: MS to stop allowing passwords in URLs Paul Smith (Feb 03)
- RE: MS to stop allowing passwords in URLs Richard M. Smith (Feb 03)
- RE: MS to stop allowing passwords in URLs Francis Favorini (Feb 03)
- RE: MS to stop allowing passwords in URLs Thor Larholm (Feb 03)
- Re: MS to stop allowing passwords in URLs Sam Schinke (Feb 05)
- RE: MS to stop allowing passwords in URLs NESTING, DAVID M (SBCSI) (Feb 05)