I have a web app that requires a user to have an account. This user can then vote 'once' on a specific item. However, some users are signing up for lots of accounts to 'game' the system.
Does anyone have any ideas how you can restrict this type of thing?
Could I restrict number of signups per day per IP address? (what are problems with this?)
Any other suggestions???
You would do yourself one better by restricting the sign-ups to just a single IP address per user. This may not be good if you plan on having families all living under the same roof to have their own accounts, but in most cases this is practical.
Yes, restricting signups per IP is reasonable. I'd probably go with signups per rolling time period (say, a maximum of one new account in any one-hour period per IP). You might also flag suspicious signups (say, more than five per day per IP) for later followup.
You might also restrict users from voting until they've passed some hurdle, similar to SO's reputation system. Prevent poll voting until they've been a user for a week, have posted at least twice, have one friend request, etc.
I remember when I ran a online RPG I flagged when more than 5 or so accounts logged in with the same IP in the same day.
People mention the NAT issue. Read the header x-forwarded-for and compare that to the standard ip address.
If x-forwarded-for is present use this value. Most properly configured NAT routers will populate this field. The only ones that do not are typically anonymous proxies.
If you really are worried about people gaming the system, using a flash bit that uses sockets to connect, and provide say, session id, to the socket listener. You can then compare that with the ip address and x-forwarded for. If it does not match, they are behind an anonymous proxy. You could feel safe to not allow them to create accounts.
This works because most anonymous proxies out there aren't full Socks proxies where all network traffic goes through it, just HTTP. This worked very well for me in the past where we had a contest with voting and folks were using anonymous proxies to game the system.
Instead of limiting by account, you could set up limitations by email address. If users need to provide their email address, you already create one hurdle for them. Make sure they have to respond to a confirmation email to make sure the email address is real. Also keep track of email address and IP address, marking any count as suspicious where a single IP address has e.g. 5 or more email addresses. (In which case you could check those addresses to see if they are somehow related, like all from the same domain or similar names.)
Sure, people can create dozens of email addresses using GMail or Hotmail or even if they have their own private domain. But for many people this is already a bit too much. Basically, if you see 5 email addresses from gmail.com with the same IP address, it's suspicious.
One potential problem is if your users are behind a NAT such as a home router, ISP proxy, or corporate firewall. You will see the same IP for all of them.
Instead of blocking people I would simply record their IPs, create a report of duplicate IPs that you can run periodically to investigate suspicious activity.
In addition you can take a social approach, post the user's IP somewhere. This will provide a gentle warning and disincentive to people who fake accounts, as well as allow your community of users to potentially identify fakers.
I would recommend implementing a different authentication mechanism such as OpenID, or are Alex said, force the users to specify a valid email and send them confirmation links via email before accounts get created.
My preference is OpenID for sure.
Related
A digital certificate issuer says that:
- an email will be sent to "registered owners" of the domain (ex. croraf.com).
How does he know who the "registered owners" of the domain are? (and how can I tell in general who the registered owners of some domain are)
NOTE: Below that it gives the option to "send an email to admin#croraf.com, webmaster#croraf.com, hostmaster#croraf.com". So by registered owners it is meant something else (perhaps names in whois lookup of the domain).
The convention is to use hostmaster, postmaster or some other "well-known" email address at a domain which is likely to be held by an entity enabled to act on behalf of that domain.
They may also pull from the whois data. e.g. for stackoverflow.com it would be reasonable to allow the email to be sent to sysadmin-team. The whois data is fairly indicative of someone who is responsible for the domain, because anyone who can cause the domain's whois data to change has the ability to repoint their DNS authority to another service (where they presumably have the ability to modify things), making someone who has "whois-edit" permissions capable of completely subsuming the domain. Therefore, whoever they say is trustworthy is as good as anything else.
Orginal Question
I want to implement a voting system on my page that is open to visitors and users i.e. non-authenticated users can vote.
Is there a rails/rack (or other) solution to identify visitors for this purpose?
Summary/Result:
If you want to implement a system where a visitor can take a certain action only once, i.e. a voting system. You have to divide your visitors into two groups:
Visitors that don't want to/don't have the tools to trick voting
Visitors that don't manipulate the result can be tracked using techniques such as: evercookie, Webbrowser Fingerprinting (panopticklick) and IP-Blocking.
Gems:
https://github.com/daddyz/evercookie
https://github.com/Valve/fingerprintjs
JS:
https://github.com/carlo/jquery-browser-fingerprint
Paid-Services:
http://threatmetrix.com
Visitors that want and can trick voting
Visitors that want to manipulate the result will and can do this. Here's a example. You can set the barrier high for those visitors, but its usually easier for them to bypass those than for you to implement them. The reasons for this are perfectly outlined by the answers to this question.
Client software identification
Web browser fingerprinting
panopticklick only identify browser configuration, not human beings. Just using a different browser (IE/FF/Opera/Chrome) on the same computer, using the same browser on a different user account on the same computer (different set of installed plug-ins, so different browser fingerprint) or using a different computer will "fool" panopticklick.
This is not a weakness of panopticklick, as panopticklick does not try to identify human beings, only Web browsers.
"Private browsing mode" should make the browser fingerprint less unique.
Cookies
evercookie, just like any sort of cookie, is specific to a user account (or a computer) : just using a different account or a different computer would give you a different identity. (Different users cannot access each other cookies because of file permissions.)
"Private browsing mode", if implemented properly, will clear all cookies, including "super cookies".
IP address
Changing IP address
Some subscribers have :
a fixed IP address;
an IP address which changes rarely;
an IP address which changes if they unplug their modem for hour, days, or weeks;
an IP address which changes almost every time they reboot their modem;
an IP address which changes every 24 h, even if they do not want that (as the IP address change will break TCP connexions).
This is not made-up. I know ISP with all these different IP allocation policies. I have no statistics about the number of users in these different categories, however.
Some ISP will make you pay just to have a fixed IP address. So I believe a changing IP address is pretty much the norm in practice for most Internet users.
Proxies
Using an anonymous proxy (including Tor) will give a different IP address, just as a VPN.
But all the proxy users (or all users of a Tor exit node) will probably have the same IP address.
Shared IP address
In almost all cases, family members will share an IP address.
Most small/medium businesses have only one outside address. This has been a problem in practice with per-IP anti-spam limit for webmails.
Almost all mobile IP users share the same IP address with a few or a lot of other users. This has been a problem in practice with per-IP anti-DOS limit! The server administrator had to list outgoing IP addresses and white-list them! Whenever the mobile ISP uses a new outgoing IP address, its clients are blocked again until the server administrator adds the new IP address.
You probably do not want to play this "game".
You can use cookie, but that can be disabled and expired, or IP address to identify the visitor. This can be tricked too, and there is a chance that from larger networks, people come with the same IP (e.g. from corporate network).
Basically there is no foolproof solution. I think the IP address can be "good enough" if nothing important depends on it.
I am building an application using Ruby on Rails. I want to do something that I am not even sure is possible;
I have a mailer that is working, however I want to enable users to send emails using their own email address in the FROM parameter. Its almost as if the ":from" parameter has no effect on the email sent.
I'm a bit of a noob when dealing with email servers so please be as detailed as possible. I doubt there is a smtp mail server set up on my hosting account, so if I need to do something like install smtp on my hosting account please be as descriptive as possible.
You are able to set the From: field to whatever you want, theoretically, but in practice you are often limited as to what you can put in there. Many email providers will automatically replace the From address with your own regardless so that you can't masquerade as someone else.
You're probably intending to do something like this:
From: Example Customer Name <name#example.com>
Also keep in mind that sending email from arbitrary domains will result in a very high chance of being flagged as spam since you are most likely not listed as as a host authorized to send for those domains which is typically implemented with SPF.
The best practice is to set the address to be something like this:
From: Example Customer Name <you#yourdomain.name>
That way you're not spoofing your actual email address, only the associated label, which is not typically verified.
I am starting to write some code for A/B testing in a Grails web application. I want to ensure that requests from the same IP address always see the same variation. Rather than store a map of IP->variant, is it OK to simply turn the IP address into an integer by removing the dots, then use that as the seed for a random number generator? The following is taking place in a Grails Filter:
def ip = request.remoteAddr
def random = new Random(ip.replaceAll(/\./, '').toInteger())
def value = random.nextBoolean()
session.assignment = value
// value should always be the same for a given IP address
I know that identifying users by IP address is not reliable, and I will be using session variables/cookies as well, but this seems to be useful for the case where we have a new session, and no cookies set (or the user has cookies disabled).
You could simply take the 32-bit number and do ip mod number_of_test_scenarios. Or use a standard hashing function provided in ruby. But I feel I should point out a few problems with this approach:
If your app is behind any proxies, the ip will be the same for all the users of that proxy.
Some users will change IPs fairly frequently, more frequently than you think. Maybe (as Joel Spolsky says) "The internet is broken for those users", but I'd say it's a disservice to your customers if you make the internet MORE broken for them, especially in a subtle way, given that they are probably not in a position to do anything about it.
For users who have a new session, you can just assign the cookie on the first request and keep the assignments in memory; unless a user's initial requests go to multiple servers at the same time this should resolve that problem (it's what I do on the app I maintain).
For users with cookies disabled, I'd say "The Internet is broken", and I wouldn't go to much trouble to support that case; they'd get assigned to a default test bucket and all go there. If you plan to support many such users in a non-broken way you're creating work for yourself, but maybe that's ok. In this case you may want to consider using URL-rewriting and 302 redirects to send these users down one scenario or another. However in my opinion this isn't worth the time.
If your users can log into the site make sure you record the scenario assignments in your database and reconcile the cookie/db discrepancies accordingly.
I'm considering adding email addresses to a marketing web app. Currently users are able to sign up and get a subdomain address that they can choose (theychoose.domain.com). So I'm thinking of also offering theychoose#domain.com for an email address they can use.
I've pretty much decided on sendgrid.com for sending email through the web interface which takes care of a ton of sending headaches. I'd also like to avoid setting up an email server if I could so I'm looking for services that allow me to set up an account and then programmatically create addresses when a user signs up. I want to find a service that will deal with all the spam filtering etc.
Also, this probably makes no difference but it's a Rails app.
One possibility is to use Google Apps Premier Edition. The API description can be found at http://code.google.com/apis/apps/gdata_provisioning_api_v2.0_reference.html.
Keep in mind though, that each user will cost $50/year. However, if you make significantly more than that per registered user, then it may be worth it.