Russell Coker wrote: > On Mon, 8 Dec 2003 13:16, Patrick Ouellette <[EMAIL PROTECTED]> wrote: > > Instead of a smartcard/token/whatever physical device, this incident > > could possibly have been thwarted by requiring developers to > > pre-register their machine with the project (using ssh host key for > > example). The attacker would have the user's account information, > > but project machines would have refused access since the host id did > > not match the user's registered hosts. Then the project machine > > could have alerted both the project's admin team and the owner of the > > compromised account. > > One problem with this is developer's machines that are on dial-up > Internet connections. In the case of such machines you can verify the > host key but not the IP address.
You cannot verify the IP address *exactly*, but you can verify whether the IP address lies within a range. Dial-up users could at least register a certain address range, so as to vastly mitigate the attack risk. Apart from that, as soon as the use of IPv6 broadens, dynamically assigned IP addresses will diminish. > But this still leaves the issue of how to deal with dial-up machines. > Even if we restrict connections to a single ISP as often dial-up > machines are not used with multiple machines, this still isn't > necessarily much good, some dial-up ISPs have >50,000 IP addresses. Still, IP address (even if it's a range, not a single address) verification vastly mitigates the attack risk. > Finally, if the attacker can compromise the machine and the machine is > online (EG permanently connected machines) there's no good options. What's more secure, "no good options", or "no good options" plus IP address verification, even if range-based? Some attack vectors one will never be able to protect against, but it still makes sense to protect against other vectors, doesn't it?