The Flaws Of Building IP Address Based Applications

0
437
IP Network man in middle

Suppose you are building a voting booth application. One of the things you want to avoid is letting a user vote multiple times to skew results. How do you prevent this from happening?

Client devices attach to the public Internet via an Internet Service Provider. With most of the world using mobile devices such as a smart phone, laptop, tablet or netbook, along with computing devices in locations like the office, home, or university, the problem building applications to uniquely identify a user to a device and IP address is an interesting one.

The short answer to “How do you prevent a user from voting multiple times?”, is, “you can’t”.

Client Devices Cannot Be Guaranteed To Be Associated With A Unique IP Address

Before we even get into this, lets be certain that there is no reliable way to guarantee that an IP address is associated with any client device. An IP address is just a number that identifies a computing device on a network. This IP address is subject to change.

An IP address is just a number that identifies a computing device on a computer network

For example, dial up companies rotate IP addresses from an IP pool, thus never guaranteeing a device to have a static IP address. Companies can use Dynamic Host Configuration Protocol (DHCP) to dynamically allocate a pool of IP addresses. As a device goes online, an IP addresses is assigned and when it goes offline it is released back to the address pool. Cable and DSL companies use a similar technique with longer lease times thus simulating a static IP address. Devices can also be anonymous through proxies.

Therefore, you cannot guarantee a device will always be associated with a particular unique IP address.

Users Cannot Be Guaranteed To Be Associated With A Unique IP Address

You cannot guarantee a person will be associated with an IP address either. Users can move from device to device. They can be at home on their desktop computer. They can be at the office on their laptop. Computing devices can also be shared among many users, like in a school or library setting.

Therefore, you cannot guarantee a user will always be associated with a particular IP address.

So What Does Our Voting Application Have To Do?

If you agree with the above two assertions, really the only thing you can do as a developer is create user accounts based on a semi-unique identity (email address) and password. Then, limiting the user to vote on only one topic.

Users who register get an email sent back to their email account. They are then asked by permission to be included as a member to your application. If agreed, they are certified, if they don’t, they are removed from the application.

Anonymous users in this case cannot abuse the voting application because, well, they are not allowed to vote. Thus you won’t have some joker come in voting repeatedly without approval.

In essence, you base the vote per account. Now sure, there is also the case where a user can create multiple accounts (based on different email addresses) but that is something really you cannot control. For example, how do you know if someone who is using your application from IBM in Tokyo isn’t the same person given all IBM Tokyo users may be using the same IP address? Sure, internally IBM will know what device and likely who that person was at the time of login and use. But to you the application developer with a server on the public Internet, you aren’t going to know that information.

ISPs, universities, and companies have the ability to collect and associate a user account and IP address to a computing device. As a server application that is made public, you don’t have that kind of information coming to you.

As an application developer you could ask the HTTP server for IP information such as:

  • HTTP_CLIENT_IP
  • HTTP_X_FORWARDED_FOR
  • HTTP_X_FORWARDED
  • HTTP_FORWARDED_FOR
  • HTTP_FORWARDED

But I see little point in creating code using this information because as described above, you cannot guarantee unique user to unique IP address.

Since I wrote this article back in 2012, the situation hasn’t really changed. What we have now is the account not only tied to email and password, but to a mobile cell phone number. Even this is not guaranteed because people can go out and purchase pre-paid cell phones for one day use. Also, cell phone numbers are recycled. A cell phone user may decide to give up his/her current number and use another one. So you cannot guarantee a user will always be tied to a certain telephone number.

Implementing any opt-in Internet application that attempts to uniquely identify a person based upon IP address and vice versa, is a waste of effort and rarely guaranteed.

A Better Idea

What can be created is a unique identifier assigned to you when you are born, like a social security number. Along with this a token and password. That would require a worldwide public database made available where all applications would be able to authenticate a user. You as the user can change the token and password, but cannot change the unique identifier. The security to this public, distributed database needs to be rock solid to avoid tampering and attack.

Having something like this would change the entire landscape of using the Internet. Every post, comment, like/dislike, etc. would come from an existing user known throughout the system.

Summary

When building public Internet applications, the best you can do to identify your user is to force them to register providing their email address and password. Everything in your account is not people based, but account based. People can create multiple accounts associated with multiple email addresses. There is no way for you to limit that and thus it is possible for your traffic and user counts to be skewed. Examples of this are on social networks like Myspace, Facebook, and Twitter.

Of Interest