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]
Message-ID: <D8A36B741FD7BF45ADE6DA228E05B19601856EBA@mostls1msgusr06.itservices.sbc.com>
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 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ