Internet Explorer does not support user names and passwords in Web site addresses (HTTP or HTTPS URLs)

This article is intended to notify Web site administrators and IT professionals about the behavior of Internet Explorer when user information is included in a Web site address (HTTP or HTTPS URL).

By default, versions of Windows Internet Explorer that were released starting with the release of security update 832894 do not support handling user names and passwords in HTTP and HTTP with Secure Sockets Layer (SSL) or HTTPS URLs. The following URL syntax is not supported in Internet Explorer or in Windows Explorer: This article is intended to notify you of this default behavior of Internet Explorer. If you include user information in HTTP or HTTPS URLs, we recommend that you explore the workarounds that are described in this article. For more information about the 832894 security update, visit the following Microsoft Web site:

Background information

Internet Explorer versions 3.0 to 6.0 support the following syntax for HTTP or HTTPS URLs:You can use this URL syntax to automatically send user information to a Web site that supports the basic authentication method.

A malicious user might 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: Note In this case, Internet Explorer 6 Service Pack 1 (SP1) and Internet Explorer 6 for Microsoft Windows Server 2003 only display "http://example.com" in the Address bar. However, earlier versions of Internet Explorer display "http://www.wingtiptoys.com@example.com" in the Address bar.

Additionally, malicious users can use this URL syntax together with other methods to create a link to a deceptive (spoofed) Web site that displays the URL to a legitimate Web site in the Status bar, Address bar, and Title bar of all versions of Internet Explorer.

For more information about this issue, click the following article number to view the article in the Microsoft Knowledge Base:

Explanation of the change in the default behavior

To mitigate the issues that are discussed in the "Background information" section, Internet Explorer and Windows Explorer no longer support handling HTTP and HTTPS URLs of this form. Windows Explorer and Internet Explorer do not open HTTP or HTTPS sites by using a URL that includes user information. By default, if user information is included in an HTTP or an HTTPS URL, a Web page that has the following title appears:Note This change in the default behavior does not affect other protocols. For example, you can still include user information in an FTP URL after you install the 832894 security update.

This change in the default behavior is also implemented by security updates, service packs, and versions of Internet Explorer that were released starting with the release of security update 832894.

Workarounds for users

URLs that are opened by users who type the URL in the Address bar or click a link

If users typically type HTTP or HTTPS URLs that include user information in the Address bar, or click links that include user information in HTTP or HTTPS URLs, you can work around this new functionality in Internet Explorer in two ways:

• Do not include user information in HTTP or HTTPS URLs.
• Instruct users not to include their user information when they type HTTP or HTTPS URLs.

If the Web site uses the basic authentication method, Internet Explorer automatically prompts users for a user name and a password. In some cases, users can click the Remember my password box in the dialog box to save their credentials for later visits to that Web site.

Workarounds for application and Web site developers

URLs that are opened by objects that call WinInet or Urlmon functions

For objects that use an HTTP or an HTTPS URL that includes user information when they call a WinInet or Urlmon function such as InternetOpenURL, rewrite the object to use one of the following methods to send user information to the Web site:

• Use the InternetSetOption function and include the following option flags:
  • INTERNET_OPTION_USERNAME
  • INTERNET_OPTION_PASSWORD
  Note For these flags, the InternetSetOption option must have a handle returned by the InternetConnect function. Therefore, if the application uses the InternetOpenUrl function, modify the application to use the InternetConnect, HttpOpenRequest and HttpSendRequest WinInet functions. For more information about how to use these functions, visit the following Microsoft Web sites:
  http://msdn2.microsoft.com/en-us/library/Aa384363 (http://msdn2.microsoft.com/en-us/library/Aa384363)
  
  http://msdn2.microsoft.com/en-us/library/Aa384233 (http://msdn2.microsoft.com/en-us/library/Aa384233)
  
  http://msdn2.microsoft.com/en-us/library/aa384247.aspx (http://msdn2.microsoft.com/en-us/library/aa384247.aspx)
• Use the IAuthenticate Interface. For more information about how to use the IAuthenticate Interface, visit the following Microsoft Web site:
  http://msdn2.microsoft.com/en-us/library/ms775080.aspx (http://msdn2.microsoft.com/en-us/library/ms775080.aspx)

Note With this workaround, you can open Web sites that the URL-spoofing technique redirects. The whole URL appears, including the redirected location. For example, the following URL appears: The user still arrives at the redirected Web site. In this example, the user arrives at http://www.example.com.

URLs that are opened by a script that uses credentials for state management

If you include HTTP or HTTPS URLs that contain user information in your scripting code, to manage state information, change your scripting code to use cookies instead of user information. For more information about how to use cookies to manage state information, visit the following Internet Engineering Task Force (IETF) Web site:To see an example of how to use Visual Basic to read and write HTTP cookies in an ASP.NET Web program, visit the following Microsoft Web site:

How to disable the new behavior or to use it in other programs

You can set registry values to use this new behavior in other programs that host the Web browser control or to disable this new behavior for Windows Explorer and Internet Explorer.

How programs that host the Web browser control can use this new default behavior to handle user information in HTTP or in HTTPS URLs

By default, this new default behavior for handling user information in HTTP or HTTPS URLs applies only to Windows Explorer and Internet Explorer. To use this new behavior in other programs that host the Web browser control, create a DWORD value named SampleApp.exe, where SampleApp.exe is the name of the executable file that runs the program. Set the DWORD value's value data to 1 in one of the following registry keys.

• For all users of the program, set the value in the following registry key:
  HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
• For the current user of the program only, set the value in the following registry key:
  HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE

How to disable the new default behavior for handling user information in HTTP or HTTPS URLs

To disable the new default behavior in Windows Explorer and Internet Explorer, create iexplore.exe and explorer.exe DWORD values in one of the following registry keys and set their value data to 0.

• For all users of the program, set the value in the following registry key:
  HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
• For the current user of the program only, set the value in the following registry key:
  HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE

For an explanation of the standard URL syntax for HTTP or HTTPS URLs, visit the following Internet Engineering Task Force (IETF) Web sites: Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.