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).
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.
Using IPSEC instead of ssl makes a successful MiTM attack much
harder, but I am sure you can envision intercept scenarios (mostly
requiring local pc infection, although this is also a reliable method of
SSL interception in the first place) where the transmission security is
bypassed rather than "broken" so it wouldn't matter if the channel were
provably unbreakable to OTP levels....
------------------------------------------------------------------------
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
------------------------------------------------------------------------
Received on May 21 2008
Intro
