Question
How can you determine if a user is unique or not?
I understand there are many ways to do this using cookies, but what about methods that don't use cookies?
For example, go to Urban Dictionary and click one of the up/down vote buttons. Even if you delete your cookies and come back to the page, you will not be allowed to cast a vote on the same definition.
How do they do this?
Purpose
Eventually, I'd like to use this unique user detection method on a site where users create accounts. New signups are given a type of "reward" and I want to prevent people from creating multiple accounts in order to exploit the reward system.
Ultimately, I don't really care what techniques are used to achieve this. I understand that no method will be 100% reliable. Even preventing this for 70-90% of users with an average computer skill level would satisfy me.
I'm guessing that Urban Dictionary (and other voting sites, such as a variety of image boards) use IP addresses to track visitors. Not 100% fool-proof, but probably pretty good for most of the time.
Note that with many of these sites, you can vote again, usually once per 24 hours (or however long they log IP addresses for).
Some things that will break this scheme: People who know how to spoof IP addersses, NAT routers, proxies (possibly). Another thing: many home ISPs these days use dynamic IP addresses, so the IP address you have right now might be different in a few hours. If you want to force a new IP address, it's usually enough to unplug your high-speed modem for a few minutes then plug it back in. Some routers also have a feature to demand a new IP from the ISP.
Urban Dictionary is probably only allowing one vote per IP. Or they could be taking a browser fingerprint https://panopticlick.eff.org/.
For tracking whether a user has been to your site before, cookies are a probably your best bet
Besides IP address and "normal" cookies, FLASH cookies may be used. FF has an add-on called "BetterPrivacy" that delete those cookies when you exit the browser. But they're less known.
Some use cookies, some force a login/email address, and some track IP address.
As FrustratedWithFormsDesigner alludes to above, if you're not going to use cookies then you've got to use IP addresses. You can combine this with the user-agent, but even that is not infallible.
IP address is commonly used but fallible, as others have said. Note that AOL (and perhaps other ISP's) use shared proxy servers for content-type requests and caching, so that a single user's requests for images may show up to your server as coming from several different IP addresses. Conversely, all AOL users' requests for images will therefore comme from these same IP numbers.
Related
Good Afternoon,
I am hoping someone might be able to help me with a concept. I have a websocket server which pushes JSON messages out to users, I have coded in a number of admin functions for pushing broadcasts out to users, as well as disconnecting users if needed.
One of the things I would like to be able to do though is to come up with a 'near' foolproof way of 'banning' users from connecting to the server if required. This is where I am a bit lost, if I go the cookie route then it is possible that the cookies get cleared and it no longer works, I can't use the session ID either as once they disconnect they get a new session ID, and the IP address is also problematic as many would be on mobile dynamic connection.
Id appreciate any tips on how to best achieve a way of remembering the users so if I ban them, when they go to reconnect I can prevent them.
The server I am running is the supersocketserver whilst the client is HTML5.
Given your current constraints, there is no "foolproof" way to ban a person from accessing your web site.
For privacy reasons, there is no permanent way to identify a given browser. There are cookies, there are IP addresses, there are even some evil "perma-cookies" that attempt to store little pieces of identifying information in lots of places (such as flash cookies and other plug-in data) to try to make it difficult (but not impossible) for users to clear them. As you're already aware, IP addresses are not permanent and are not always tied to just one user either.
And, of course a user can certainly just use a different browser or computer or mobile device.
So, the usual way to control access is to require a user to create an account in your system before they can use your service. Then, if you want to ban a user, you ban that account. Since you will want to prevent the user from just creating a new account, you can collect other identifying information upon account registration. The more info you require and can verify, the harder it is for users to create more and more accounts. This gets to be quite a bit of work if you really want to make it difficult for users to create more accounts because you need to require pieces of identifying information that you can both verify and are hard for a rogue user to duplicate (credit cards, email addresses, home addresses, etc...). How far you go here and how much effort you put in is up to you on how much you want to keep a banned user out.
How can a website "remember" user information aside from cookies?
For example, there was a time when I was browsing on a newspaper website (New York Times), and I had reached the ten limit article count. Usually, I just deleted the cookies, and that would bring the article count back to zero and I could continue browsing again.
However, lately, deleting all the cookies on my computer no longer works as a way to bypass this article count block. As such, I was curious as to what other possible ways could be used to "remember" one's user information (in this case, the number of articles a user has browsed) aside from cookies.
There was also another instance where I was forever banished from a site; deleting my cookies again didn't work in accessing it - the site somehow had a way of "remembering" who the banned users were.
The most obvious answer is your IP address.
While not perfect, IP address blocking can be used to identify you and deny you access.
In particular, its commonly used to detect what country a visitor is coming from to enforce content distribution laws.
The requirements:
For each item in the shop, keep stat about visitor's view.
During the first 15 mins, do not count the same visitor even though that visitor re-open the web browser
Need a way to protect visitor's cheating (The above 2 requirements should always be apply)
For example of cheating, If we're using Cookies, this is not good enough, WHY? Visitor can disable cookies and press "Refresh" to increase the stat(visitor's view)
Any good solution?
You have only two possibilities:
Track cookies / flash cookies (which many people don't even know of): That means tracking on the machine of the user
Track IP addresses: That means tracking the users on your server (you keep a database of IP addresses which have visited your site during the last 15 minutes or so).
Both possibilities can be "cheated". Cookies can be deleted, IP addresses can be changed. There is no absolute bulletproof way to accomplish what you want (Thank God for that!).
OK, you could force your users to login, then you could track everything down to a specific user account - no more cheating (well also not true: what about duplicate accounts...). But without such a limitation... no way.
Is using a User's IP addr as part of a Cookie's hashed value that I store in the database a bad idea? I read somewhere that since most user's have dynamic IP addresses that it was bad practice to use this as part of the hash. If so what kind of user data should I pull in the hash? Or do I really need to?
Thanks.
While dynamic IP addresses (using DHCP) are an issue, they're not likely to change in small timeframes. The real problem arises from the fact that some users are behind proxies that make requests from different IP addresses all the time.
It might make sense in some Intranet environments, but I believe for a public Internet facing Web site, it's an absolute no-no.
Bad idea. There are a number of large ISPs (AOL worldwide & Virgin cable in the UK among others) that route all their users through a (relatively) small number of proxy servers, but the actual server they use, can and does change between almost every request.
If you do want to uniquely identify particular (non-logged-in) users, without requiring a back-end store, some kind of GUID may be useful.
I'm creating a website and I don't want to have user/membership.
However, people using the site can do things like vote and flag questionable content. Is the only way to identify and prevent users from doing this repeatedly by using cookies?
I realize a user can just clear their cookies but I can't think of another way.
Suggestions for this scenario?
Well you could map a cookie + ip-adress in a datarecord in your database. To identify the user. So if the ip exists in the database, you simply just add the cookie, but check the cookie first to avoid unessesary database calls.
This is not optimal though, since schools etc might have the same ips on a lot of computers.
You can always just adapt openid!
Marko & Visage are correct,
Just to add though, you might want to store each vote with the timestamp,IP, etc... so at least if someone does try to "game" your site, you'd be able to rollback sets of votes made from the same location or within a very short amount of time (i.e. from a bot)
+1 To all that others have already said. Here's another middle-way idea:
Use cookies as primary means of limiting voting. If a cookie is not found, check the IP address. Allow no more than, say, 1 vote per 5 minutes from the same IP.
Cookies are not enough, as you said it could be cleared/expired.
IP address tracking is also not an option because of DHCP and firewalls.
The only thing that is ~100% sure is users, but then again, one person can register multiple accounts.
I'll go with cookies, as the simplest ant least obtrusive way. If someone really wants to play the system, he will find a way whatever you try to prevent it.
Even with membership a user can register multiple times and vote.
Cookies are one way to handle this but people who know that they can delete cookie can vote again.
You can catch the IP of the voter and restrict based on that. But many people will have same IP.
Sadly there is no other way.
Yes, you are right.
HTTP is stateless, so there is no way of determining if the origin of a request you receive now is the same or different to the origin of a request you received, say, 5 minutes ago.
Cookies are the only way around this. Even server side sessions rely on cookies to maintain session identity across requests (ignoring the security nightmare of passing the sesison ID in the URL, which anyone with malicious intent can sidestep trivially).
There will always be people gaming the system if it suits them. Moreover, if you make it such that you don't need cookies at all you'd be open to very simple attacks.
I think you'll want to consider ways to increase the economic cost of users operating under a cloud of suspicion.
For example, if a user with the same cookie tries to re-submit the vote, that can obviously be stopped easily.
If a user with a different cookie but from the same IP does the same thing, it could be coming from a proxy/firewall so you may want to be cautious and force them to do something extra, like a simple CAPTCHA. Once they've done this, if they behave properly nothing new is required as long as their new cookie stays with them.
This implies that people without cookies can still participate, but they have to re-enter the letter sequence or whatever each time. A hassle, but they're likely used to sites not working without cookies. They'd be able to make an exception if required.
You really won't be able to deal with users sitting over a pool of IPs (real or otherwise) and exploiting new and dynamic attack vectors on your site. In that case, their economic investment will be more than yours and, frankly, you'll lose. At that point, you're just competing to maintain the rules of your system. That's when you should explore requiring signup/email/mobile/SMS confirmation to up the ante.
You can add GET variables and URL parts to serve as cookies - some sites do that to allow logins and/or tracking when cookies are disabled. Generate the part using source IP and user agent string, for example.
site.com/vote?cookie=123456
site.com/vote/cookie123456