Re: username and Password sent as clear text strings

[David Howe <DaveHowe.Pentest () googlemail com>]

Matthew Zimmerman wrote:
> David, Marvin Simkin said it well; I didn't.

Sorry, I obviously mistrimmed. correction noted :)

> On Tue, May 20, 2008 at 4:43 AM, David Howe
> <DaveHowe.Pentest () googlemail com> wrote:
> > Matthew Zimmerman wrote:
> > > In my opinion, if you want to mitigate this, don't use passwords.  Use
> > > true challenge-response.  Everything else proposed here is either
> > > obfuscation or doesn't really work in a web application environment.
> > > A VPN around a webserver only works if every user that needs access to
> > > that webserver can also access the vpn.
> > that is unfortunately only security though obscurity, and barely worth doing
> > - it raises the bar quite a bit (in that the MiTM attacker must also modify
> > the transmitted page to request a plaintext password instead. a much more
> > demanding task than just recording traffic) but requires that you send
> > javascript, java or flash code to actually do the challenge-response
> > protocol (and manage the inevitable clients who will have that turned off
> > then complain that your site "requires" things they consider a security
> > issue).
> Maybe I didn't state it correctly, challenge/response was the wrong
> term to use.  PKI, SecurID, etc.  Something that involves something
> you are or something you have in addition to something you know (e.g.,
> a password).  You are correct that obfuscating the password by some
> client side script/addon will not work.  That was not my intention.

  A lot depends on what you are doing at this point, the value of the 
host to the attacker, and the attack modes. Client side certificates are 
rarely used now (in fact, I can think of only one site I used that 
offered them - CA's support channnel - and they have removed support for 
that in their move to their new solution) which is a pity given they are 
a good, cheap and effective solution to a lot of issues. They aren't a 
*portable* solution, but the vast majority of users are either static in 
their access needs (they use a single or small number of hosts) or are 
able to carry a pkcs #12 on inexpensive media or external storage. (the 
security of adding a hard-to-remove clientside certificate to a webcafe 
host is awkward to manage however)

  Physical tokens are in vogue; they are easy (relatively) to use, very 
portable, and require no special hardware or software at the client 
side. The downsides there are the inevitable turnover (loss, failure or 
expiry of tokens), the fact that a physical token will often be left 
with or near the user's customary access point (so for laptops, will 
often be left in the carry case) vulnerable to abuse or theft given 
physical proximity, and the perceived security of the token being so 
high that often social engineering or MitM fake-failure attacks can 
achieve entry of a token value under the control of the attacker without 
arousing the suspicion of the user. And the cost, of course (which isn't 
to be neglected; tokens are not cheap). Unless logins in parallel are to 
be prevented, often a single token value can be used in parallel (for 
example - BHO captures a token based login and transfers that login data 
to the attacker's machine, which then (within seconds of the first 
login) attempts a second login with the same token value. Unless the 
token value is invalidated by the first successful login (or the 
attacker is unlucky and has expired by the time he attempts his login) 
then he will be left with his own copy of the session independent of the 
real users

> >  Ultimately though, if your attacker can successfully read and modify the
> > browser channel (either using browser plugins or indirectly by intercepting
> > and modifying the page stream via a MiTM attack) or intercept the data entry
> > channel (keyboard/mouse) you have already lost.

> Right.  You break the SSL tunnel, you also have the user's cookie,
> which means you don't care about a "password" anymore.  The cookie is
> your password.

  Pretty much, yes. often the cookie value will be tied to the IP 
address, but in MitM scenarios often the ip address of the attacker *is* 
the IP address the server sees, both for legitimate and for compromised 
traffic.

  I don't claim to have the answers, but I do have some pretty good 
questions :)

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Top 5 Common Mistakes 
in Securing Web Applications  
Find out now! Get Webinar Recording and PPT Slides

www.cenzic.com/landing/securityfocus/hackinar
------------------------------------------------------------------------