bugtraq - RE: MS to stop allowing passwords in URLs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <003a01c3ea61$ad514e60$0100a8c0@aardvark>
Date: Wed, 4 Feb 2004 00:56:12 +1030
From: "Andrew Harwood" <aaharwood_maillist@...pond.com>
To: "'McAllister, Andrew'" <McAllisterA@...ystem.edu>,
	<bugtraq@...urityfocus.com>
Subject: RE: MS to stop allowing passwords in URLs

RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt) states is section 3.3
(Note the last sentence):

-------------------
-- begin excerpt --
-------------------
An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>

   where <host> and <port> are as described in Section 3.1. If :<port>
   is omitted, the port defaults to 80.  No user name or password is
   allowed. 
-----------------
-- end excerpt --
-----------------

So Microsoft has finally just adopted the RFC standard, not broken it.

Anyway, you can always re-enable the old system, as documented in the
Microsoft document you link, viz:

-------------------
-- begin excerpt --
-------------------
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:
HKEY_LOCAL_MACHINE\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE

For the current user only:

HKEY_CURRENT_USER\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
-------------------
--  end excerpt  --
-------------------

The other options are more secure in some ways, most specifically if the
address is visible anywhere on screen, there is no reference to the
username/password for anyone who passes by. I have this problem with our
help desk at work - they have a PC which has the username/password of
our network monitoring system visible in the URL, which any client who
visits can see. Which is one reason why I will only give them read
access :-)

Further, the other options (at least yet) have no ways of breaking them
that will hide the real URL you are visiting, since they only handle the
username/password, and have no linkage to the actual web address.

That's my 2c anyway.

-- 
Andrew Harwood
aaharwood@...pond.com

-----Original Message-----
From: McAllister, Andrew [mailto:McAllisterA@...ystem.edu] 
Sent: Thursday, 29 January 2004 09:24
To: bugtraq@...urityfocus.com
Subject: MS to stop allowing passwords in URLs

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@....somehost.com/

See http://support.microsoft.com/default.aspx?scid=kb;en-us;834489

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. 

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.
Click the applet and it opens a browser window with the
id:passowrd@...ver.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.

I certainly don't consider the "remember my password" functionality nor
stored cookies any more or less safe than this syntax.

Anyone have any comments regarding legitimate uses of this syntax and
Microsoft removing it from their browser? (and presumably the OS since
the browser IS the OS).

Andrew McAllister
University of Missouri