On 02/06/2011 09:38 AM, Florian Weimer wrote:
The IP address restriction is a pretty strong factor. Basically, it
means that a potential attacker would have to compromise a device
quite close to the user (possible the terminal itself).
We end up in a deep discussion about this every few weeks at work.
My personal opinion is that IP source addresses are not actually a
particularly strong factor. Here are some reasons:
* IP source addresses are basically self-reported by the unauthenticated
sender. Source address authentication is built on the hope that it is
hard for the attacker to inject or observe packets on the target network
so he will be unable to originate a TCP connection.
* Originally IP did not attempt to provide any security properties and
IP routing is not always configured with these attacks in mind. Even
backbone routing is essentially an environment of implicit trust. There
have been notable cases of unfriendly parties taking over netblocks
which supposedly belonged to others.
* Bad guy only needs to pwn one box or app on the "trusted" network.
Often he can choose from hundreds to attack.
* A misconfigured (or with out-of-date firmware) blue-box Linksys home
router/firewall on the internal net could be leveraged for its NAT
* DNS rebinding attacks
* An HTTP CONNECT proxy could find its way onto the trusted LAN without
anyone realizing it
* Often, there is Wifi open, crackable, or having a weak password
* Minor point: hardcoding IPv4 addresses into configs may not be the
best long-term plan considering that we're officially out of them
So probably it can be useful on a very carefully-managed network, but
even minor mistakes will tend to result in a silent vulnerability.
If you deal
with such attackers, very few reliable options exist. For Bugzilla,
things are extraordinarily difficult because you don't want to protect
transactions, but read access to certain bugs.
Yeah that makes it much harder.
The bad guy doesn't necessarily even need to originate his own TCP
connection. He can entice the target user to visit a web page which
loads an image that makes the http request. The user's browser may have
a cached session cookie. In the absence of SSL, he may be able to view
the response.
As a result, extending the IP address restrictions, possibly using
crypto tunnels such as OpenVPN, are probably a better investment than
hardware tokens.
What does a VPN get you that a solid SSL/TLS setup does not?
Sometimes adding more moving parts can just make things worse. For
example, an attacker can often leverage a VPN login into access to a
website if the VPN client and the web server support a compatible auth
protocol like MS-CHAPv2/NTLMv2.
- Marsh
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
