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>] [day] [month] [year] [list]

Date: Wed, 4 Feb 2004 09:44:36 -0600
From: "NESTING, DAVID M (SBCSI)" <dn3723@....com>
To: bugtraq@...urityfocus.com
Subject: RE: MS to stop allowing passwords in URLs

-----Original Message-----
From: David B Harris [mailto:dbharris@...f.ddts.net] 

> Or, hey, a different on-screen representation? Something like, I dunno,
> "http://user:pass@...e/" being turned into "http://site/ (user: user,
> password: pass)"?

IMO, even this doesn't go far enough.  We need to eliminate the use of URLs
as authenticators entirely.  Sites are popping up all over the place with
*legitimate* hostnames confusingly similar to real ones.  Getting tricky
with URL encoding is only part of the problem.  Users need to start
*expecting* to see an SSL- or TLS-validated identity before they trust that
they're seeing content from someone they think they are.  You wouldn't walk
into a store front with "Micro Soft" scrawled in crayon and reasonably
expect to receive legitimate Microsoft products in return for your cash, but
this is what people are falling victim to every day on the web.

Every non-authenticated web page needs to be treated as unauthenticated, and
browsers should make this clear up front.  Users need to understand that
when they are interacting with a web page at "example.com", they're only
PROBABLY interacting with the "example.com" Internet domain.  Instead, they
believe they ARE interacting (in a trustworthy fashion) with "Example
Widgets", even though there's no trusted relationship between "Example
Widgets" and example.com they can see, other than example.com saying they
are.

Eliminate a user's dependence upon the URL as an authenticator (and a search
engine, for that matter, guessing "www.<search term>.com"), and you
eliminate the bulk of the problem here.  People can do all of the stupid
encoding tricks they want at that point and it won't matter, since the URL
becomes almost entirely a machine-usable piece of data anyway, and the
computer isn't easily deceived by such tricks.

David