Re-Enable user:pass@ IE functionality.

Here's a dillema:

On one side you want to keep your machine up to date with all latest patches, but then there is "Cumulative Security Update for Internet Explorer (832894)", which disables the user:pass@ way of authentication.

Now, do you update and loose this functionality (which can be handy), or don't apply it but have the other security it fixes unpatched?

Here's what I did:

I patched.

...

But I really, really wanted the user:pass back, and it's even in an RFC MS has linked.

 

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:

//<user>:<password>@<host>:<port>/<url-path>

Some or all of the parts "<user>:<password>@", ":<password>",
":<port>", and "/<url-path>" 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.

 

 

The solution? Re-enable it!

Start regedit.

Go to:
HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
to re-enable it for the entire machine,

or go to:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
to re-enable it for the logged in user.

Now create iexplore.exe and explorer.exe DWORD values and set their value data to 0.

Done, you just got the user:pass@ functionality back.

 

Update:

As Kent Sharkey writes, the RFC I quoted actually did not specifiy the user:pass possibilty for the HTTP protocol. I'm sorry for that, it's a 'feature' I guess :)

This registry tweak does however not undo the patch, it only reactivates this 'feature', the chr(0) exploit remains fixed with this tweak.

Update2:

Here is a .reg file to re-enable it system-wide.

6 Comments

  • They appear to have fixed both the display bug _and_ dissabled Authentication, so re-enabling it shouldn't expose you to the display bug again, but you'll still be exposed to addresses like &quot;microsoft.com{lots-of-random-garbage}@202.49.168.192/&quot;.



    It's only a matter of time until someone finds -another- bug in IE, and the scammers will get another two-month window to exploit it before MS produces a patch.



    The safest way to get that functionality back is to download a 'better' browser..

  • Oh, one other thing; in the past people have found registry hacks to change other undesirable behaviour in Windows (Messenger, for example) and some time later a Microsoft patch changes it back. So if you do apply this hack, expect that it will break again with random security updates and you'll have to keep applying it.



    Apparently &quot;Trustworthy computing&quot; involves randomly changing the user's desired configuration.

  • Well, I followed all the steps, tryed doing it manually and I didnt have my user:pass back. Then I tryed the file you guys have, downloaded it and ran it, upgraded the registry, still didnt work... You guys have any idea what am I doing wrong? I of course rebooted my computer, but it still didnt work... Please help!!!

  • W00T, ended up working somehow.... =P Thanks anyways doh! =)

  • thanks for this :)

  • therefore I used it for this novel site name (for Automation people). It is also the reason it is widely used by spammers to hide adresses.



    Regards / Ake.Hansson.se (just type hansson with a @)



    I quote from a W3C document:



    3.2.2. Server-based Naming Authority



    URL schemes that involve the direct use of an IP-based protocol to a

    specified server on the Internet use a common syntax for the server

    component of the URI's scheme-specific data:



    &lt;userinfo&gt;@&lt;host&gt;:&lt;port&gt;



    where &lt;userinfo&gt; may consist of a user name and, optionally, scheme-

    specific information about how to gain authorization to access the

    server. The parts &quot;&lt;userinfo&gt;@&quot; and &quot;:&lt;port&gt;&quot; may be omitted.



    server = [ [ userinfo &quot;@&quot; ] hostport ]



    The user information, if present, is followed by a commercial at-sign

    &quot;@&quot;.



    userinfo = *( unreserved | escaped |

    &quot;;&quot; | &quot;:&quot; | &quot;&amp;&quot; | &quot;=&quot; | &quot;+&quot; | &quot;$&quot; | &quot;,&quot; )



    Some URL schemes use the format &quot;user:password&quot; in the userinfo

    field. This practice is NOT RECOMMENDED, because the passing of

    authentication information in clear text (such as URI) has proven to

    be a security risk in almost every case where it has been used.





Comments have been disabled for this content.