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 (at) googlemail (dot) com [email concealed]> 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
------------------------------------------------------------------------

[ reply ]