Forum question.

It actually is. Cookie stealing can be done with a simple Javascript injection (e.g. cross-site scripting), while IP address spoofing is much harder. Forging the source address of an IP packet is easy, but that only lets you do UDP "fire-and-forget" attacks and half-open TCP SYN attacks. Logging in to a website requires a TCP three-way handshake, which means that packets sent by the server to the source address need to reach your machine. In practice, this requires you to either be on the same subnet (and possibly the same network switch) as your intended victim, or it requires you to be able to announce routing information to the Internet at large.

Spoofing an IP address isn't that hard. If I have access to your network behind a NAT router, it's really easy. Or if I'm using the same proxy as you (e.g. on a corporate intranet), I likely don't even have a choice and must have the same IP address as you. And of course, if I have access to any upstream router, it's trivially easy, as I can simply man-in-the-middle you.

Using an IP address for any validation or authentication purpose whether it's the only method used or part of another method is dumb, period. It only accomplishes making things more difficult for legitimate users without much, if any, added security. The correct way to handle session hijacking attacks is to use a token that periodically expires, and to record old tokens to look for replay attacks. If you see one, you invalidate all of the user's sessions and, depending on how paranoid you want to be, alert the user that something fishy happened. (Though you might want to build in a little bit of tolerance in case a user did something like recently restore their system.) If you do this, it doesn't make a hill of beans difference if you're dinking around with IP addresses or not.

IP spoofing is easy, under certain limited circumstances. Cookie stealing is easy under a much larger range of circumstances. By tying a session to an IP address (or a small IP address range, to make things easy on dialup users), you make cookie stealing useful only under the limited circumstances where the attacker can also perform an IP spoofing attack. Time-limiting a session token provides protection against "steal and use later" attacks, but provides no protection against "steal and use immediately" attacks.

But you will affect far more legitimate users than shady ones. Dynamic addresses are extremely common. In some environments with load-balanced proxies, tying sessions to an IP address can completely break a site for legitimate users because successive requests can actually come from different IP addresses. Been there, done that.

Believe me, I've seen this firsthand. Depending on an IP address to be stable from visit to visit is ineffective and will only tick off legitimate users who have to continually log in (kind of like, you know, the OP who started this thread). If you're protecting something so secure that you're willing to tie the session to an IP address, you need to not count on persistent logins and validate the username and password on each visit. Otherwise, seriously, don't bother. If it's not a critical enough application that you don't want to account for someone being able to spoof an IP address, then it's not critical enough to be a pain in the butt for anyone with DHCP-assigned dynamic address or who uses a laptop at multiple locations.

Doesn't actually belong here. But Union and Defiant are the historical UK servers. So if you're looking for the main body of people who're on at the same time you are, those are the two to hit first.

Nowadays *all* of the servers are in English, so it honestly doesn't matter where you go.

Clicking on the linked image above will take you off the City of Heroes site. However, the guides will be linked back here.