Using DNS Pinning To Cookie Users
I’ve been toying with an idea for several months that I think I’ve finally got to the point that’s worth talking about. One thing that can be a big problem is mapping anyone behind a NAT. If there are a number of people using your site that use the same IP address it can be difficult to separate them into different users. Although this method is hardly fool proof it can help distinguish between users as long as they don’t close their browser regardless if they don’t use cookies, or allow any other form of session information to be written to disc.
So here’s the concept. The user connects to your DNS server, and gets an IP address with a very short TTL. The IP is unique for some period of time. The user will continue to use that IP address with the hostname given for the duration of their session, regardless of what they do. Other users who connect later will see a different IP. Of course, once the user shuts down their browser and restarts it they too will see a different IP, but that may be enough for certain applications. This would be most effectively used on a single static image or some sort of tracking mechanism so that you don’t have a high overhead. In general this is a pretty heavyweight solution, but it could be useful to some people out there.
February 20th, 2007 at 2:06 pm
what about nscd’s and other ways of caching the dns? that would break this.
also - non-portable cookies are a bad design. even in your example (and if implemented improperly regardless of how perfect your design is), it is possible to get a login page looping issue. IOW: client DoS.
maybe if you used a machine-id concept like cookie-revolver?
i would think that less than 1% of users don’t use cookies… and you can always force them to…
February 20th, 2007 at 2:53 pm
I think you’re sorta missing the point. This would be for detection of users, not for authentication. This would be a scenario where someone might dump their cookies (although keep their browser open) and re-login.
February 20th, 2007 at 5:49 pm
Dont think this will work for detection either. Client DNS queries accept the first answer they get back which most often is not from your authoritative NS.
Theres also the issue of caching proxy servers to consider as well. Once your tracking bug is cached, all further client requests will not result in a new HTTP session from the proxy to your server.
February 20th, 2007 at 6:46 pm
Of course it would work… hahah… yes, there are some instances where it will fall down, and yes, users can shut down their browsers. Caching of the pixel itself is super easy to get around by appending a unique string to the end of the URL.
Come on, think outside the box for a second. Just because there are a few issues doesn’t mean it has zero value.
February 20th, 2007 at 8:00 pm
RSnake - what would you achieve though? Say I’m behind a corporate firewall that’s using PAT (one public IP many RFC1918 IPs). I go to www.rsnake.org which resolves to say 15.1.1.1. A colleague of mine makes the same request and gets 15.1.1.2. Is that the idea? Assuming this is it, what do you get other than knowing there are are least 2 IPs “hiding” behind my PAT address?
February 20th, 2007 at 8:16 pm
So… you’re making a Dynamic DNS system except that the IP rotation happens faster than the TTL lets it on to be. Barring non-client level caching (we need the client to cache for this to work, but if anyone else caches it things don’t work), this allows us to uniquely identify users. That’s pretty heavy.
Why not try something a little lower-tech: if the browser has history caching enabled, could HTTP caching be used to a similar effect?
February 22nd, 2007 at 3:23 am
Could this be used to prevent session hijacking?