Microsoft update disables user:password in URLs

February 4, 2004 12:55 PM

With its latest security update Microsoft has disabled the ability to pass username:password pairs in URLs. If you usually use this format for connecting to your site via either FTP or HTTP, it will no longer work after you install this update.
posted by johnnydark (34 comments total)

reason number 637,523 not to use ie.

all snarkiness aside, i've managed to get my entire family, including my 85 year old grandmother, to switch to firebird or mozilla.
i don't understand why anyone who is savvy enough to use username:password pairs in urls would still use ie.
posted by dolface at 1:02 PM on February 4, 2004

Oh this is lovely. We just implemented this new FTP server and we sold people on it based on the fact they could log in using these sorts of URLs.

Now we have to.... do.... something... else...
posted by xmutex at 1:08 PM on February 4, 2004

All I know is I could have grabbed or deleted about 4 people's thesis work when I typed in ftp:// into one of the grad room PCs' url bars and saw the username / passwords there all waiting to be pillaged.

But I did the good samaritan thing and cleared the history.
posted by Space Coyote at 1:08 PM on February 4, 2004

Are you sure it's also disabled for ftp? I don't use windows myself, but I think I heard someone claiming it still worked for ftp after the update.
posted by fvw at 1:12 PM on February 4, 2004

Jesus. I noticed this change today when accessing an FTP link and wondered what was wrong. I restarted my PC like three times thinking I had a .dll error or something.

If XP's system restore doesn't fix this I think I've finally just been sold on Mozilla.
posted by XQUZYPHYR at 1:14 PM on February 4, 2004

I'm reminded of this old joke:
Patient: Doctor! It hurts when I do this.
Doctor: Well, don't do that, then.

We installed IIS 6 at work a few months ago, looking forward to it's improved security. What we didn't realize was that it was more secure because it ships with almost everything turned off by default. Once you spend the days turning things back on one by one we found it wasn't really much more secure at all. This IE update follows exactly the same philosophy.
posted by stevis at 1:24 PM on February 4, 2004

This could very well be the work of the porn lobby. All those "XXX Password" sites put authentication into the URLs.

I think. Maybe. Not that I'd know, or anything.
posted by majick at 1:29 PM on February 4, 2004

Microsoft, hindering computing and business advances, BECAUSE THEY CAN!

The best argument I know of to use Mozilla or Safari is tabbed browsing. Far and away the most useful advance in browser technology.
posted by fenriq at 1:32 PM on February 4, 2004

We installed IIS 6 at work a few months ago, looking forward to it's improved security. What we didn't realize was that it was more secure because it ships with almost everything turned off by default. Once you spend the days turning things back on one by one we found it wasn't really much more secure at all. This IE update follows exactly the same philosophy.

But that's the only thing, practically, that makes IIS 4 and 5 insecure!* It's all the extra functionality, other than BEING A WEB SERVER, that hardly anyone ever uses. There've been few vulnerabilities discovered within core IIS functionality - most are in ISAPI filters and extensions that are enabled by default, but that hardly anyone uses.

* slight oversimplification - running as SYSTEM is kind of a problem, too, but it's required by IIS so that it can impersonate other user accounts.
posted by me & my monkey at 2:20 PM on February 4, 2004

their temporary fix was to copy and paste urls rather than clicking them. As lame as this is.. much better than the previous fix.
posted by Tryptophan-5ht at 2:25 PM on February 4, 2004

I can't believe people are still using FTP at all. I use it a little around the LAN, but SFTP is standardized and ubiquitous, so... why not use it? As for not sending username-password pairs in URLs... I thought people stopped doing this five years ago. I guess there are too many bad administrators leaving legacy systems in place for far too long.
posted by squirrel at 2:29 PM on February 4, 2004

I heard someone over at /. saying that user:pass isn't part of the official RFC for http anyway. (Apparently, it may or may not be an optional part as described by a reply to that post). So all they are really doing is being standards compliant. How ironic.
posted by tcaleb at 2:30 PM on February 4, 2004

squirrel: when you have a whole bunch of people who are barely aware that they are using this thing a "web browser" then it's a little hard to start educating them on SFTP clients, etc.
posted by xmutex at 2:31 PM on February 4, 2004

Passing sensitive information in a URL has always been very insecure, and not everybody knows this.

Always read the details before installing a software update. If you don't like it, don't install it.
posted by ukamikanasi at 2:35 PM on February 4, 2004

So what the hell is SFTP then?
posted by inpHilltr8r at 2:43 PM on February 4, 2004

What makes this funny is, as some both here and on Slashdot noted, that the user:pass@ function is most commonly seen with membership-related sites. In other words, porn. It's the simplest (translated: cheapest) form of security-entry for websites.

Given that a major law of new technology is that its success is directly correlated with its application to porn (if that rule doesn't have a name yet I'm claiming it right now), I have a feeling the protests from the 80% of the internet associated with adult sites will force Microsoft to fix this by the end of the week.
posted by XQUZYPHYR at 2:43 PM on February 4, 2004

inpHilltr8r: secure FTP; i.e. FTP over SSL (secure socket layer). The FTP equivalent of HTTPS.

I tried to explain without using acronyms but I failed!
posted by xmutex at 2:51 PM on February 4, 2004

If you're spreading user:pass via URLs, what's the point of having validation in the first place. May as well use a "secret" URL for all the security it affords you.

Obviously, anyone posting here can figure out how to operate those little login box thingies...
posted by Ogre Lawless at 2:51 PM on February 4, 2004

user:pass@url addressing is in RFC1738 but specifically not recommended in the superseding RFC2396.

Opera has warned before going to address in that format at least since version 4.
posted by TimeFactor at 2:53 PM on February 4, 2004

inpHilltr8r: secure FTP; i.e. FTP over SSL (secure socket layer).

Actually, while there are a few bastardized ftp over ssl implementations out there, SFTP is typically used to refer to an ftp connection over ssh.
posted by piper28 at 3:07 PM on February 4, 2004

I would prefer you not refer to my FTP over SSL implementation as bastardized, piper28. It's sensitive.
posted by xmutex at 3:13 PM on February 4, 2004

I downloaded the fix, but it doesn't seem to effect ftp at all, (see for yourself).

But I hate the format and it's too east for scammers to fool people using the @ in a url, like those april fools jokes that link to fake news stories, example.
posted by bobo123 at 3:43 PM on February 4, 2004

I only just found out about this feature? here and now they are taking it away? That sucks.
posted by dg at 4:27 PM on February 4, 2004

Why do you hate America ^H^H^H^H^H^H^H^H^H Microsoft so much?
posted by Slothrup at 7:19 PM on February 4, 2004

This is really going to cut into my one-handed viewing of stolen porn.
posted by UrbanFigaro at 7:45 PM on February 4, 2004

This really sucks for me when I have to use a public computer, like at Kinko's, that doesn't already have an FTP program there. Because of their security settings, you can't install a new FTP program or access Network Neighborhood stuff. FTP'ing through a browser was my only resource for moving large things in this situation.
posted by destro at 9:38 PM on February 4, 2004

destro:

Start -> Run -> ftp.exe

open example.org
[Read RFC 959.]
bye

Enjoy.

(actually, ftp is pretty simple to learn)
posted by shepd at 10:05 PM on February 4, 2004

wait... i'm confused. this update doesn't actually disable IE's own browser based ftp feature does it...? if not, that's something destro could use, no...?
posted by t r a c y at 10:37 PM on February 4, 2004

So all they are really doing is being standards compliant.

That would be incorrect.

It is not part of the standard for HTTP but is part of the standard for URLs. URL include more than HTTP addresses.
Relevant excerpt:

RFC 1738: Uniform Resource Locators (URL) - Berners-Lee, Masinter & McCahill
http://www.ietf.org/rfc/rfc1738.txt
. . . snip . . .

3.1. Common Internet Scheme Syntax

While the syntax for the rest of the URL may vary depending on the
particular scheme selected, URL schemes that involve the direct use
of an IP-based protocol to a specified host on the Internet use a
common syntax for the scheme-specific data:

//:@:/

Some or all of the parts ":@", ":",
":", and "/" may be excluded. The scheme specific
data start with a double slash "//" to indicate that it complies with
the common Internet scheme syntax. The different components obey the
following rules:

user
An optional user name. Some schemes (e.g., ftp) allow the
specification of a user name.

password
An optional password. If present, it follows the user
name separated from it by a colon.

The user name (and password), if present, are followed by a
commercial at-sign "@". Within the user and password field, any ":",
"@", or "/" must be encoded.

Note that an empty user name or password is different than no user
name or password; there is no way to specify a password without
specifying a user name. E.g., has an empty
user name and no password, has no user name,
while has a user name of "foo" and an
empty password.

host
The fully qualified domain name of a network host, or its IP
address as a set of four decimal digit groups separated by
".". Fully qualified domain names take the form as described
in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
[5]: a sequence of domain labels separated by ".", each domain
label starting and ending with an alphanumerical character and
possibly also containing "-" characters. The rightmost domain
label will never start with a digit, though, which
syntactically distinguishes all domain names from the IP
addresses.

port
The port number to connect to. Most schemes designate
protocols that have a default port number. Another port number
may optionally be supplied, in decimal, separated from the
host by a colon. If the port is omitted, the colon is as well.

url-path
The rest of the locator consists of data specific to the
scheme, and is known as the "url-path". It supplies the
details of how the specified resource can be accessed. Note
that the "/" between the host (or port) and the url-path is
NOT part of the url-path.

The url-path syntax depends on the scheme being used, as does the
manner in which it is interpreted.

. . . snip . . .

posted by nofundy at 5:05 AM on February 5, 2004

Good thing my clients are too incompetent to know how to update their software, or this might actually be an inconvenience.
posted by GhostintheMachine at 5:25 AM on February 5, 2004

nofundy, that is all I meant. I am not talking about FTP, SSH, Telnet, or any other the hundred other services that use URIs. This discussion isn't about URLs (or URIs) in general; it is about MS removing use of user from the http addressing. Which as you said yourself isn't part of the HTTP RFC. I was trying to make a pretty limited point.
posted by tcaleb at 5:58 AM on February 5, 2004

Also, I am not trying to be argumenative. I get what you are saying and I see how it can interpeted that way. Maybe I am just totally missing the point, but I would think that a HTTP specific RFC would trump a general RFC describing URL in general.
posted by tcaleb at 6:04 AM on February 5, 2004

According to the knowledge base article, this patch should only affect HTTP and HTTPS and not FTP.

The same article also give instructions for disabling this "feature" while keeping the rest of SP1 (such as the double-scroll bug fix, which is itself worth the price of admission).
posted by Monk at 7:41 AM on February 5, 2004

I understand tcaleb.
You made a very good and positive contribution (in my opinion) as I also hoped to do.
posted by nofundy at 9:57 AM on February 6, 2004