I'm planning to add some vote up/vote down buttons to a website I run. This seems easy enough but I want to stop people voting multiple times. One solution would be to make them register before allowing them to vote but I'd prefer not to have to force them to register.
Is there are a reasonably straightforward way of doing this? Checking the IP address doesn't seem like a good solution, since it's possible that multiple users may come from the same IP address.
Cookies might be the answer, but a savvy user could delete the cookie. Any better ideas?
Sorry I don't have a useful answer, I just want to share my experience.
About 8 years ago I worked for a site that ran online polls. We once got hacked by some bots voting on some of our questions several hundred votes a minute.
I had to implement some emergency checks: IP address, cookies, and I really don't remember what else.
At the end of the day we decided to take the polls down. Those damn robots just didn't care. IP adresses were spoofed, cookies were being deleted, etc.
If you really really need the polls to be unhackeable I don't see any other way that requiring registration and using captchas to avoid bots signing up for new accounts.
And the sad thing is that this was just an entertainment site with polls on what's your favorite color and things like that.
The only thing we didn't tried was using captchas because they didn't exist at the time. That might have reduced non-human cheating a good deal.
Don't take this as any kind of expert advice on the matter, because that was the only time I had anything to do with online polls, but I remembered my story and wanted to share.
I think it really comes down to the nature of your website, and how accurate your results needed to be.
Using a cookie seems like the best option, but it depends on the target audience of your website. Would they be tech-savvy enough to try and beat the system to allow them to vote multiple times? If not, the risk should be fairly low and this would seem like the best approach.
Checking against an IP address, as you said, may be too restrictive. But if it's critical for all votes to be from unique individuals, this might be the better approach even if it means some legitimate voters won't get to vote.
I thought of another option, but I'm not sure if it's possible or feasible. If you could combine the IP address approach with a hardware based check (e.g. MAC address of NIC) this would eliminate the IP address approach being too restrictive due to NAT within a LAN. But it wouldn't help the situation where you have a computer in an Internet cafe used by different individuals.
You should also use captcha (for non registered accounts) to reduce the likelihood of voting bots. If someone wants to maliciously cast multiple votes, making it more difficult for them to automate the voting process through bots will help to hopefully reduce the occurrence of such behaviour.
So, you want to have each unique person have only one vote on each item. When a person tries to vote who has already voted before, you want to detect this. This means that you have to identify the person. There are no tricks to get around that.
Now, since persons can log in from any computer, identifying the computer doesn't help. This rules out IP checks and cookies, as well as anything else based on the user's hardware.
How to identify a person? You can't. You can only force them to identify themselves, by providing unique credentials, like a social security number (I think this is often used in Korea), a passport number, or similar. This, of course, doesn't help if you don't check it, since anyone can make up a 10 digit number with little chance of collision.
Even having the user register doesn't really help per se -- they can just register another account.
I wonder if you could make it a multi-step process, to make it more difficult for BOTs.
Registering, or some similar task, gets you Cookie-A, and then when you vote you get Cookie-B, but if you have Cookie-B and don't have a suitable matching Cookie-A your vote doesn't count. If you try to re-register on the same machine that can be detected by you already having Cookie-A. Going through the steps too fast is treated as a BOT.
We had a psychometric test, with many questions, and users had to make thoughtful answers. An answer in sub-N seconds was someone just pressing buttons to get through it. We never told them that their answer was too quick, we just marked the data as "suspect".
So anyone trying to go straight to the Vote Button won't work. They would have to do Step-A, then Step-b then Step-C in order.
To re-vote I would have to clear cookies, re-register, read the blurb-page (whatever) and finally re-vote, all in the right order, and not too fast.
Requiring JavaScript to be enabled may help, as may a Captcha system. Captcha could have some sort of delay - "Please watch as the two words appear" so that there are two words, shown one after another, but "real words" so that they can be easily memorised, and then typed in. Any response that is "too fast" is not valid.
At some point people will just become annoyed and not bother though.
Obviously you need to identify the user so he can only vote once. But identify the user does'nt mean you have to pop up a login screen. As said above you can ask for the email
address, ans use it as an identfier.
No one mention the way stackoverflow works, if the user has something to win (here reptutation) when becoming a register user and if the login process is as simple as giving an email address, then that's a win-win situation in wich the user is happy to login and vote, and you're happy to have him registered and voting things (and only once per question).
Jeff Atwood wrote an article about the "login barrier", wich may give you clues.
I once created a voting system for a contest. I was restricted from limiting votes by IP due to the fact that multiple people would be legitimately voting from the same IPs. As such, I went with the email confirmation method, requiring each voter to input an email address which a confirmation link was sent to, which, once clicked, would activate their vote and prevent additional votes using that address.
It did not work well. People created hundreds of false email addresses on various free sites.
What did work in the runoff vote, somewhat surprisingly, was adding the email address/vote pairs to a database but not immediately sending the confirmation emails out. Instead, I had a cron job send the batch of them every 15 minutes or so. This adds an additional complication for people registering many addresses, as they have to either leave them all open or remember the login info for each of them at some point in the future.
Of course, still easily bypassed for someone motivated enough, but it seemed to work well in this case.
I've never used a system like this, but try to identify a user by their browser's fingerprint. This jQuery plugin combines screen size, color depth, user timezone, and installed plugins to create a unique ID of a user. Definitely not foolproof, but it's a different approach.
There's no accurate way to avoid multiple votes from the same user, even if they don't delete cookies, they can use another browser, or another computer.
I think you should register user before he up / down vote. You can get a little piece of information from the user to get registered, so he does not bored or break his registeration. Afterwards he can update his account if he wants. IMHO this is the best solution.
As has been said there is no 'perfect' solution.
As an attempt at an imperfect solution, how about storing a hash of the IP address and the User agent.
This would mean that different users from a given IP, which have different browser user agents, can still vote.
Use a cookie-based approach, it is accurate enough for most entertainment-grade polls on the web. Stay away from IP restrictions. This would mean that only one person from larger companies gets to vote and that only one person in a family gets to vote.
Also a possibility:
let the user vote and fill out his emailaddress.
The user receives a confirmationemail with a link he needs to click in order to confirm his vote.
But this way, the user also has quite some overhead.
Or do this in combination with registered userss (who will not be forced to confirm)
I know that this is an old thread. In any case I suggest to use evercookie (http://samy.pl/evercookie/) to track a user that have already voted!
It's matter of how many identities a single person can control. The more harder you make for a single person to control multiple identities the more secure your poll will be.
For entertainment grade polls where the results doesn't matter, single cookie approach is enough. Very easy to circumvent if the user opens icognito windows.
Better protection can be obtained if you put a registration barrier, you can use OAuth based logins for seamless authentication, it would take some effort to switch accounts for more votes. But this doesn't stop the desperate ones to vote multiple times.
Even better if you send confirmation code in SMS. Though people may own multiple phone numbers, it's not common to have a considerable number of phone numbers to execute a fraud. But this approach costs money for you and can be abused by DoSing the server to exhaust all the SMSes.
If you want goverment-grade polls, where the votes can decide an election.
Then you should have the voters show up in the registration office to apply for the poll and let them choose one from the prepared PIN envelopes, which contains a long hash they can enter when casting the vote.
So unless the organizers commit a fraud then voters can't. This also ensures anonymity.
An old question but for to touch on new ways - these days there are many Poll services out there who work tirelessly to implement numerous measures to avoid dupe votes, and constantly tweak their systems to counter new ways people introduce to circumvent etc. Doing this yourself is a job in itself.
They even offer branding. And large corporations use them, so it's not like your company will look bad for outsourcing a poll.
If you need to do it yourself.
As has been said, registration is the only sure fire way. If it's really important to avoid dupe votes (i.e. it's not just fave colour or something trivial/fun) then you can also limit voting to a link you send to their email they registered with.
While still not fool proof (nothing is) at least you force them to have a genuine email address which they have access to.
This isn't too much trouble for users voting, but makes it fiddly to make many dupe votes - registering, waiting for email, using the link, etc.
You already named all usable solutions. ;) It's your task to decide now.
I'd recommend combining an IP and cookie check.
Related
I searched a lot about what is the best way to secure your program and I found many results and there were two good ways.
The first one is to hash the mac address of the computer and link it with an activation code but it's still vulnerable.
And the second one is to use a usb device but I didn't find any detail so can anybody tell me in details what is the best way and how to implement it please.
First of all, you need to consider that it doesn't matter what you do, someone will be able to crack it, and because of this is that you need to consider a balance between the security of your application and how hard you will make it for legitimate users (since you don't want to punish a user who already paid for your product, just because you want to protect your applications from the guys who don't want to pay).
Having this in mind, you could go with digital signatures using asymmetric encryption, where you'll sign your license "activation" with your private key, and then your application will use its public key to verify that the received license was submitted by you. You should also take a look at this discussion (I recommend you to focus on the 2nd answer, not the selected one) and this one.
But again, your objective should be to just make things hard for bad guys, but without punishing your legitimate users, because for an attacker, it could be as easy as de-compiling your program and removing your logic to validate the license (unless you're creating an "always online" application, but usually users don't like that, and I'm saying this as a user).
I have an IIS hosted website that is getting lots of suspicious data coming in from the contact form. What I mean by suspicious is that there are people whose names and address and phone numbers are all valid, but when my company contacts them they have never heard of us. We attempted to use a CAPTCHA to help prevent this, but it merely slowed it down. We would filter out the IP addresses, but it is never using the same IP twice and it is not using it in ANY pattern we can recognize. I am at a loss here as to what to do to keep them from giving us bad data. The problem, also, is that I am not entirely sure it is a Bot since they are coming in at a pace that COULD be a few people doing one right after the other, though this seems unlikely since they come in ALL the time. Does anyone have any suggestions on, if it IS a bot, keeping it form submitting the form or identifying it after the form has been submitted? Also, is there any way to tell for sure that it IS a bot?
Why do people have to enter data? Is it to download something? People will always enter any false data if it's to get at something they feel doesn't need their personal info. 'Any info' is not the same as 'accurate info'.
Your problem is not bots, but perhaps imposing your want for unwanted info.
Also, depending on the captcha, some are easier to bypass than others, but why would people want to bypass it if they gain nothing (such as a link on your site) in return?
The talk of internet town today is the SNAFU that led to dozens of Facebook users being led by Google search to an article on ReadWriteWeb about the Facebook-AOL deal. What ensued in the comments tread is quickly becoming the stuff of internet legend.
However, behind the hilarity is a scary fact that this might be how users browse to all sites, including their banking and other more important sites. A quick search for "my bank website login" and quickly click the first result. Once they are there, the user is willing to submit their credentials even though the site looks nothing like the site they tried to reach. (This is evidenced by the fact that user's comments are connected to their facebook accounts via facebook-connect)
Preventing this scenario is pretty much out of our control and educating our users on the basics of internet browsing may be just as impossible. So how then can we ensure that users know they are on the correct web site before trying to log in? Is something like Bank of America's SiteKey sufficient, or is that another cop-out that shifts responsibility back on the user?
The Internet and web browsers used to have a couple of cool features that might actually have some applicability there.
One was something called "domain names." Instead entering the website name over on the right site of your toolbar, there was another, larger text field on the left where you could enter it. Rather than searching a proprietary Google database running on vast farms of Magic 8-Balls, this arcane "address" field consulted an authoritative registry of "domain names", and would lead you to the right site every time. Sadly, it sometimes required you to enter up to 8 extra characters! This burden was too much for most users to shoulder, and this cumbersome feature has been abandoned.
Another thing you used to see in browsers was something called a "bookmark." Etymologists are still trying to determine where the term "bookmark" originated. They suspect it has something to do with paper with funny squiggles on it. Anyway, these bookmarks allowed users to create a button that would take them directly to the web site of interest. Of course, creating a bookmark was a tedious, intimidating process, sometimes requiring as many as two menu clicks—or worse yet, use of the Ctrl-key!
Ah, the wonders of the ancients.
The site could "personalize" itself by showing some personal information,
easy recognizable by the user, on every page.
There are plenty of ways to implement it. The obvious one:
under first visit, the site requires user to upload some avatar,
and adds user's id to the cookies. After that, every time the user browses
the site, the avatar is shown.
When I set up my online bank account, it asked me to choose from a selection of images. The image I chose is now shown to me every time I login. This assures me that I am on the right website.
EDIT: i just read the link about the BoA SiteKey, this is apparently the same thing (it sounded from the name like a challenge-response dongle)
I suppose the best answer would be a hardware device which required a code from the bank and the user and authenticated both. But any of these things assume that people are actually thinking about the problem, which of course they don't. This was going on before internet banking was common - I had a friend who had her wallet stolen back in the 90s, and theif phoned her pretending to be her bank and persuaded her to reveal her PIN...
When the user first visits the site and logs in, he can share some personal information (even something very trivial) that imposter sites couldn't possible know - high school mascot, first street lived on, etc.
If there's ever any question of site authenticity, the site could share this information back to the user.
Like on TV shows/movies with the evil twin. The good twin always wins trust by sharing a secret that only the person who's trying to figure out who the good twin is would know.
You cannot prevent phishing per-se but you can take several steps each of which do a little bit to mitigate the problem.
1) If you have something like site-key or a sign-in seal, please ensure that these cannot be iframed on a malicious website. Just javascript framebusting may not be enough as IE has security="restricted".
2) Be very consistent about how you ask for user credentials - serve the login form over SSL (not just post-back over SSL). Do not ask for login on several places or sites. Encourage third parties who want to work with user data stored on your site to use OAuth (instead of taking your user's password).
3) You should never ask for information via email (with or without link).
4) Have a security page where you talk about these issues.
5) Send notification on changes to registered phone, email, etc.
Apart from above, monitor user account activity - such as changes to contact information, security Q&A, access, etc (noting time, ip, and there are several subtle techniques).
I am the webmaster for a small, growing industrial association. Soon, I will have to implement a restricted, members-only section for the website.
The problem is that our organization membership both includes big companies as well as amateur “clubs” (it's a relatively new industry…).
It is clear that those clubs will share the login ID they will use to log onto our website. The problem is to detect whether one of their members will share the login credentials with people who would not normally supposed to be accessing the website (there is no objection for such a club to have all it’s members get on the website).
I have thought about logging along with each sign-on the IP address as well as the OS and the browser used; if the OS/Browser stays constant and there are no more than, say, 10 different IP addresses, the account is clearly used by very few different computers.
But if there are 50 OS/Browser combination and 150 different IPs, the credentials have obviously been disseminated far, and there would be then cause for action, such as modifying the password.
Of course, it is extremely annoying when your password is being unilaterally changed. So, for this problem, I thought about allowing the “clubs” to manage their own list of sub-accounts, and therefore if abuse is suspected, the user responsible would be easily pinned-down, and this “sub-member” alone would face the annoyance of a password change.
Question:
What potential problems would anyone see with such an approach?
Any particular reason why you can't force each club member to register (just straight-up, not necessarily as a sub or a similar complex structure)? Perhaps give each club some sort of code to use just when the users register so you can automatically create their accounts and affiliate them with a club, but you then have direct accounting of each member without an onerous process that the club has to manage themselves. Then it's much easier to determine if a given account is being spread around (disparate IP accesses in given periods of time).
Clearly then you can also set a limit on the number of affiliated accounts per club, should you want to do so. This is basically what you've suggested, I suppose, but I would try to keep any onerous management tasks out of the hands of your users if at all possible. If you can manage club-affiliated signups, you should, rather than forcing someone at the club to manage them for you.
Also, while some sort of heuristic based on IP and credentials is probably fine, I would stay away from incorporating user-agent, or at least caring too much about it. Seeing a few different UAs from the same IP - depending on your expected userbase, I suppose - isn't really that unusual. I use several browsers in the course of my day due to website bugs, etc. and unless someone is using a machine as a proxy, it's not evidence of anything nefarious.
We would like to run a wireless access point for public use. However, in case of misbehavior, we would like some personal information to be able to pass on to law enforcement.
The proposed solution involves a captive portal where users enter their email addresses, and are then given ten minutes to check their email and verify, after which they are given unrestricted access.
The problem, as I see it, is that once a user is authenticated, anyone can come along, spoof the MAC or IP, and then have access. If they commit a crime or copyright infringement, the user who entered the email address is now blamed.
Now, we could solve that by using WPA and requiring users to preregister. But as I said, we would like to allow anyone to just drive up and use it, and we don't want to provide any technical support.
The other alternative is not collecting email addresses, but then in case of an investigation or lawsuit, we wouldn't have anything to hand over, and thus risk the possibility of being shut down.
Is there any way out of this dilemma?
Collecting email would also be futile since you have no good way of confirming it without also providing compromised access. You should simply log the traffic that the user generates.
The answer is to not care about unsatisfiable demands from law enforcement for the personal information of your users. If that's not an acceptable answer, then the answer is to stop trying to provide a public access point. If that's not an acceptable answer either, then the answer is the proposed solution you already have. How you go about living with yourself afterward, for collecting personal information from law abiding people that will only ever be used by criminals to cover their tracks, is a personal matter and out of scope for this site. Good luck.
Having the end-user accept a legal disclaimer that you (the provider) are not responsible and they (the end-user) is responsible, and that they should not do illegal things is usually good enough. Just log that they clicked "I agree" and their IP and MAC at the time. They should have to do this every time they connect.
Asking for an email is basically worthless; many will use a made-up email, or enter a typo, then complain they never got it - many will use a disposable email - many will use a junk account they create with one of the free webmail providers.
A system that sends their mobile phone a TXT message with a unique (random) code, and having that entered on the captive portal page to gain access is a better system IMHO. I've done this before and it works OK, except for kids who have mommy's iPad or another tablet but no phone. You save all this data for 90+ days, or however long your lawyers tell you.
Realize that implementing any of this significantly decreases the actual use of your hotspot, users don't have the patience and will be frustrated and abandon the process.
Most captive portal products can log the MAC and IP lease every client gets, and where they go on the Internet (at least that's how I do it) so if a legal request comes along, you can give law enforcement the data you have. It's up to law enforcement to then steak out or track down the device with that MAC, which depending on their competency level is possible, or impossible for them, either way it's not your job to do their job for them.
I also advocate filtering the obvious porn and malware domains, not just to save on bandwidth, but to limit your liability. Any good captive portal product can do this.
Your public wireless network should at the least be NAT'd to a separate static IP, so you can differentiate legal requests that reference that IP, as opposed to say your private office network. You can do this with separate firewalls, or a firewall that supports multiple LAN interfaces.