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.
Related
If my shopping cart is stored in a DB for both anonymous and registred users, what is the best way to protect it from an attack? I found a lot of discussions about where to store shopping carts but nothing about this matter.
What if some bot just doesn't store cookies and sends requests to the shopping cart over and over again. Without cookies it's different anonymous user every time thus database will grow.
Should I check the ip address and redirect to a captcha? But real users may have same ip addresses, so the algorithm should be more complicated to not disturb them.
Any ideas or links?
Captcha's are a pretty popular way to go. I'm guessing most people (like me) rather dislike them and generally can't read them, but they're generally probably pretty easy to implement and more efficient than most alternatives.
The less effort approach to checking IPs is having all anonymous users require a Captcha.
I would also suggest having a time-out (based on activity) of no more than a few hours on carts of anonymous users (after which you can probably delete it).
You'd also want an upper limit on the number of items, and, if this number is high, also possibly prevent (though Captcha?) users from adding too many items to their cart in inhumanly short succession.
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.
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.
I'm looking for a way for users to be able to connect to my application easily, but rarely. What I want to do is be able to store a cookie with a 1 year life on the user's computer. If they access the website while the cookie is active, they will be automatically logged in.
My proposed solution is this: Upon initial login, create a cookie with the users IP address, last login date, and random number, all hashed together. I will also store their user ID and IP address in cookies as well. These values will also be stored in the database. If after a few months they access the site again, the IP address, ID, and hash match the values in the database, then they are automatically logged in. A new hash is computed. If any of these don't match, then the user will be prompted to log in again.
Are there any obvious security flaws to this design? I am not worried about IP addresses changing, this will be for professors on a university campus.
Thanks in advance,
--Dave
Your question does not make it clear how this system is any different from any other standard long-life cookie. Those are used across the web without significant security problems, so I see no reason you could not also use a cookie in a similar fashion.
Are there any obvious security flaws
to this design?
No.
I would say it's definitely a security risk if someone figures out the system. To be honest, I would rethink that setup, at least the storing it in a database part. Not to mention the fact that cookies very rarely stay on someone's computer for a year anyway, most people clean them far more frequently.
But since you asked, creating it is pretty easy:
$expire = time()+(60*60*24*365);
setcookie("login", "mycookie", $expire, "", "yoursite.com" );
Instead of "mycookie" you could insert that token you were talking about. Hope that helps a little.
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