Question

We recently attempted to add ip address validation to our website s login security. So in addition to having a cookie with valid credentials, we checked that your ip address on page request matched the one you initially signed in with. The idea was that if your cookie is stolen, a different user cannot impersonate you unless they actually are on the same IP address.

For the majority of users there was no issue, but it seems some ISPs (namely AOL and BT) use some sort of proxy farm that actually gives the user a different IP address on every single outgoing connection, which of course made login impossible for those users. The addresses in some cases were completely different between requests also, so even checking the upper octet or similar doesn t appear feasible.

We had to rip it out. My question is if there is any way of detecting these types of ISP configuration to exclude them from the IP check, or any general advice on how to enhance security without including IP address. It appears to me that online banking sites do the above, but perhaps they just have short time to live on the cookies.

Answer 1

ISPs are the least of your worries. You ll also have problems with corporate users with laptops which go from docked to undocked and get a new IP address each time. And large corporate proxy farms often act like AOL s. I d strongly suggest you ignore IP address consistency in your security approach-- it s a big headache with questionable return.

Answer 2

You are right, there isn t a perfect solution. If you want to ease up on the restrictions, your best bet is to validate based on user-agent. It isn t full-proof, but it is better than nothing.

Answer 3

I would set a timer so that you record not only which IP address they came from, but when they last came from it. After a user comes from the same IP address for a certain number of pageviews, say three, then go ahead and push down basically a lock_ip cookie to the user or make a note of it in your session variables on your side. Then use that to indicate that the session should be locked to the IP. If you use the cookie approach, you ll want to make sure you record this in a database on your side somewhere as well so that an attacker can t simply show up with the older cookie or without an extra lock_ip cookie, depending on how you implement it..

Answer 4

Signed cookies that take into account the user agent and source IP are OK, if you really need to be that tough.

To combat proxies, use HTTPS. If you re talking about security, always use HTTPS before other measures.

To combat check for different source IP-s (if you really need to) you could try whois and AS numbers.

友情链接