So i am running into a problem with people making multiple accounts to make there account better with more resource in game.
So my dilemma is, Many users go thru proxys or NATd info so some legimated users would be banned if i only have 1 user per ip.
Is there a way (with Javascript and PHP) to Get a uniq identifier specific to a computer (without Hardware changes, computer hardware change probably would change the identifier).
Any idea or comments would be much appericated
(The following was revived from a response made by Paul, but deleted by another for being out of place.)
I cant change the client to much because its a browser based game so getting the hwid would be possible. But how with JS or PHP.
Adding timers and restrictions to prevent transfers are in place but doesnt stop them entirely there is an option to email for an IP exception. but that is slow an tedious. Im wondering if there is a definitive to generate a specific id or identifier for a specific computer (Not ip based) that would make it so multiple accounts cant be logged in from the same computer but can be logged in from the same ip
As we are talking about a different account, probably on a different IP and client, you cannot easily find out clone accounts.
You can go for two more heuristic and gameplay options
As suggested before (by #dqhendricks), divide your resources and implement your sharing etc in such a way that you can't easily help your other account with every new account. Make finding other accounts in the beginning hard/impossible, make shareable resources a higher level feature etc. Downside is that this changes the gameplay, it doesn't have to be desireable.
You can perform heuristics on behaviour. There can be specific behaviour that is unwanted: only interaction with 1 other account etc. You could tweak some of the variables etc, but you could easily see suspicious behaviour. Make some sort of 'balance' calculation. Most ingame interactions have some sort of balance. Ofcourse, better players may have a good deal because they know more, or the other way around: they make a bad deal to help smaller players. But when one player only gives and never takes, it's "helping" without acutally playing itself: that might mean it's a clone
Everything with ip-adresses or client-information ($_SERVER) etc is worthless in this case as far as I'm concerned..
You could prevent multiple logins on the same Account (username/password).
If the issue is that they make multiple accounts with many different email addresses etc... and new usernames and passwords then you might be able to do it with Cookies for example that use a unique hardware id and then you simple check that not more than one account is active at any one time based on this hwid. if the hardware changes it doesnt matter as it is relative.
To clarify if the HW id for the first login is 1234 then the second login with generate the same hwid. If you check the cookies or your database (doesnt matter where you store it) for the same hwid then you know its already logged in.
If the hardware changes it doesnt matter as they will still both generate the same hwid.
If they use two computers though the haardware id will be different and this will work.
{sharable resources} = {total resources} - MAX(({starting resources} - {spent resources}), 0)
make only non-starting resources sharable, or maybe make sharing resources an ability you don't gain until level x.
Preventing spoofed/duplicate accounts (while ensuring all legitimate accounts work) is a very difficult task -- for reasons laid out by others. In addition to trying to guard against concurrent multiple accounts, one must guard against non-concurrent multiple account usage.
The core issue isn't so much in determining where an account connected from, but being able to trust that a user only has one account -- and to this end the only "real" solution is to use a system which already provides this sort of information, such as a credit card or paypal account ;-) That is, simply prevent someone from creating a new account (although an account can have multiple aliases/profiles, but these can be trivially tracked) unless they can prove "uniqueness".
(Also consider that two people may have two different accounts on the same machine.)
Happy coding.
I run an online game server aswell. To prevent your dilema, either modify the game client to read the MAC Address, and only allow 1 account per computer. Or log the ip's and only allow the resources to be given to that ip twice.
3rd option: Don't allow transfering of materials from the same ip addresses
4th option: Add a timer on the transfering of resources, make them wait 10 minutes of gameplay before they can do anything like getting rid of the items for others to get
Related
The website that I am currently designing has run into a bit of a snag - basically my client has mad it clear that he needs a one person = one account feature, now I'm not the best at analytic's (despite my programming background) so I could really use some suggestions.
We are programming in PHP, and I'm 100% aware that there isn't a solution that would 100% prevent the problem, but I need as close to the 100% as I can get and so far I have tried...
Placing cookies to the users browser. Workaround - Switch browser.
Tracking IP. Workaround - change IP, reset router etc. (Also, more than one user per IP is permitted).
Using analytic's to try and track actions such as Account A being logged out, then a minute later account B logging in from the same IP. (This seemed to be the most effective, but it took a few people to keep it going so I'd like to automate it as much as possible or if possible eliminate the need for manual monitoring.
The problem is that the users of my clients site will be paid depending on different actions and my client has already decided on a $10 minimum withdraw amount, and payments will be handled via PayPal.
So basically multiple account usage could cost my client a lot of money if the site goes live without these features.
I would also like to keep this back-end (possible cron-tab). Just to be clear.
Any help/input/suggestions at all will be massively appreciated.
Tah
PS- I have already checked out this question (Account verification: Only 1 account per person) which is where I got the idea for point 3 from.
The only way to really prevent a person from signing up for multiple accounts would be to ask them for personal information specific to them. I ran into this issue and ended up having to track social security numbers to prevent multiple accounts. Granted, the project I was working on was for a school and the school already had this information. Also, for a new user signing up, it wasn't unusual to them to give this information.
Reading some of the comments, I can say that even if PayPal had a way to track duplicate accounts, it is highly unlikely that you would be granted access to this information, even just to say "yes this is a duplicate" or "no it is not a duplicate".
I really think SSN would be your best bet.
AFAIK iovation uses a set of tracking methods, including Flash cookies and browser fingerprinting to track the users and the devices used. Although budget-wise it might not be your best option, you may consider the techniques themselves.
I'd suggest the business to create incentives for using a single account, which might pay off better than (costly?) fancy tracking software.
What is the best way to implement limits for users in applications like discussion boards, image hostings etc. ?
Let's say we want to set limits for StackOverflow. Anonymous users should be able to post 50 questions per 12h and registered users 100 per 12h.
I thought about creating a database and storing information about IPs/users and their posts. Data would be erased after 12h.
However, such solution can be easily hacked. A single IP shouldn't generate more than 100 questions, but what if one user create several accounts on the same IP? Every account has its own limit, so user could generate unlimited amount of questions.
I would have to limit number of accounts per IP (what with schools/other places with many users and single IP?).
I could write on this topic for months. This is a super hard problem that is not solved with a single silver bullet...if this is a real problem for you, you'll solve it over and over as you move forward.
If there is value in putting large amts of content on your site, as you get to scale, bad guys will discover this and get around your defenses. You'll need to look at what they are doing, adapt and attack the problem different. This is why the GMail spam team still exists. :) Deep pockets, smart gals/guys on that team. If it were "solvable" they would have solved it by now.
Doing something like what you describe above is a great start. I would also invest in instrumentation & push the data off to a platform where you can analyze it after the fact (ex: a Hadoop cluster). This way you can study the livesite traffic to see if you have a problem and, if so, learn about how they are doing it so you can adapt.
Welcome to the Hotel California...where you can check out anytime you like but you can never leave.
Most systems use IP based for non-authenticated users and per account on authenticated users. If people are going to sign up for multiple accounts to circumvent your security then you can either use captcha to remove bots and/or a cooling off period for new accounts before they are allowed to post or even use ip based until the account is at least 24 hours old.
You have already answered your question, if I were you, I would have done following things :
1. Limit number of accounts created per IP
2. Set a DB which maintains records or counter for content created in past 12hours
3. For guest, however could be tricky, you can use IP+cookies to track user's activity, however could be problem if there are many users behind a single proxy. For that, either you have to sacrifice your rules or be strict.
I have seen many website when I am behind proxy, they say you have already visited this site but I never.
This will not fix 100% of your problems and might bring some other in.
Instead of using completely anonymous users and registered users and check IP's, anonymous users should present a working email as verification and a temporary identifier (which will not be publicly shown ofc) each time they post a question.
As they post question it will be saved along with the email and they should receive question activation link in their mailbox.
If they click the link in email, question gets activated and published, so the email servers as a temp identifier instead of client IP.
Ok, it is still possible that some people might use like 10 different email accounts and spam you with questions, and it may even scare some people off.
I'm creating a voting system for my PHP/MySQL website and I would like to make sure one user can only vote once. What would be a good way of doing this? So far I have thought of and semi-implemented the following:
Storing individual votes in the database with an IP and vote. This creates bulkiness but ensures that each user gets one vote.
Storing a cookie on the user's end to check if they've voted or not. This is the most simple but obviously users can just disable cookies.
What would be the most practical approach? Any other suggestions are more than welcome.
The Unobtainably-Perfect: (Unique Govt Number)
User votes using a verifiable unique identifier like a social-security or passport number
The Close-Enough-For-Reality: (Email/3rd Party Auth)
user registers an account with an email address and password (or google/facebook)
1 email address = 1 vote
Users can't clear cookies and get extra votes, App doesn't shut 1000's out with shared IPs
The Good-Thought-But-False-Pretense (IP addresses)
Office buildings: 1000's of users on the same external IP get shut-out
Universites: Connect to wireless in classroom. Vote. Move to next classroom. Reconnect and vote again
The Crash-And-Burn (Cookies)
Vote
ctrl shft del enter
vote
repeat
You should store as much information as you can in a database if you want to have any chance of auditing your system. If you log a lot, then even if there has been voting fraud you might be able to detect it and cancel those votes.
The second method is completely insecure. Users can just delete the cookie if they want to vote again and you will have no way to detect that this has happened.
Important note
There is not a one-to-one mapping between IP addresses an people. Some people have many IP addresses, whilst other people share a single IP address.
A fully reliable way is going to be tricky. Both your ideas have problems - cookies can be disabled, and one user may have many IP's and/or many users may share the same IP. Forcing your users to register and only allowing one vote per registered account would be better, but then someone might signup for multiple accounts. Forcing unique email verification for each account reduces this somewhat, but you could still get around it by signing up for multiple different emails.
Basically, each measure you take makes it more difficult to get around, but also increases the effort of voting at all in the first place. Short of tying votes to something known unique (SSN, passport number) that can be verified, any measure you put in place can be circumvented, it just depends on how much effort it is. Manually reviewing suspicious looking votes would help to reduce fraudulent votes too though, in addition to other measures. Where you drawn the line between ease-of-use and security is up to you really, depending on how much you need to enforce the one vote limit.
As Mark Byers said, some countries might have dynamic IP addresses (e.g. Vietnam) so the IP addresses will consistently change every time a user establishes a connection (or reset the modem). But if you can ensure that your system is built in a country where IP addresses are static, then it's fine.
The cookies solution seems to be a bit insecure, but if most of your users are non-tech people then they won't be able to recognize the trick (which is to delete the cookies and vote again). For me I don't prefer this way as long as I know my users don't know anything about this technique.
I suggest you to have email verification for the poll, so that the results will be more accurate. A user might only have a few email addresses, and they don't want to create new ones just to vote.
Whatever it is you decide to go with, IP addresses will not be secure at all. A user can basically access from a different location and vote again etc. Cookie is a solution but not optimized because of deleting possibility (so u risk the user recognition process). You will need to handle more data from the user to be able record their option securely.
if the system is a sub-system of a bigger system, maybe you can use a field that is common in bigger system to identify users in current system.
Hope this helps,
The only way to make sure users vote only once is to create user accounts Because:
Cookies can be erased
IP address are meant to change. (also, multiple users could have one IP address)
Storing individual votes in the database with an IP and vote. This creates bulkiness but ensures that each user gets one vote.
That is Good but slow than 2nd but still i recommend this.
Storing a cookie on the user's end to check if they've voted or not. This is the most simple but obviously users can just disable cookies.
you're right its insecure but little faster but i don't like this
I am about to write a voting method for my site. I want a method to stop people voting for the same thing twice. So far my thoughts have been:
Drop a cookie once the vote is complete (susceptible to multi browser gaming)
Log IP address per vote (this will fail in proxy / corporate environments)
Force logins
My site is not account based as such, although it aggregates Twitter data, so there is scope for using Twitter OAuth as a means of identification.
What existing systems exist and how do they do this?
The best thing would be to disallow anonymous voting. If the user is forced to log in you can save the userid with each vote and make sure that he/she only votes once.
The cookie approach is very fragile since cookies can be deleted easily. The IP address approach has the shortcoming you yourself describe.
One step towards a user auth system but not all of the complications:
Get the user to enter their email address and confirm their vote, you would not eradicate gaming but you would make it harder for gamers to register another email address and then vote etc.
Might be worth the extra step.
Let us know what you end up going for.
If you want to go with cookies after all, use an evercookie.
evercookie is a javascript API available that produces
extremely persistent cookies in a browser. Its goal
is to identify a client even after they've removed standard
cookies, Flash cookies (Local Shared Objects or LSOs), and
others.
evercookie accomplishes this by storing the cookie data in
several types of storage mechanisms that are available on
the local browser. Additionally, if evercookie has found the
user has removed any of the types of cookies in question, it
recreates them using each mechanism available.
Multi-browser cheating won't be affected, of course.
What type of gaming do you want to protect yourself against? Someone creating a couple of bots and bombing you with thousands (millions) of requests? Or someone with no better things to do and try to make 10-20 votes?
Yes, I know: both - but which one is your main concern in here?
Using CAPTCHA together with email based voting (send a link to the email to validate the vote) might work well against bots. But a human can more or less easily exploit the email system (as I comment in one answer and post here again)
I own a custom domain and I can have any email I want within it.
Another example: if your email is
myuser*#gmail.com*, you could use
"myuser+1#gmail.com"
myuser+2#gmail.com, etc (the plus sign and the text after
it are ignored and it is delivered
to your account). You can also include
dots in your username (my.user#gmail.com). (This only
works on gmail addresses!)
To protect against humans, I don't know ever-cookie but it might be a good choice. Using OAuth integrated with twitter, FB and other networks might also work well.
Also, remember: requiring emails for someone to vote will scare many people off! You will get many less votes!
Another option is to limit the number of votes your system accepts from each ip per minute (or hour or anything else). To protect against distributed attacks, limit the total number of votes your system accepts within a timeframe.
Different approach, just to provide an alternative:
Assuming most people know how to behave or just can't be bothered to misbehave, just retroactively clean the votes. This would also keep voting unobtrusive for the voters.
So, set cookies, log every vote and afterwards (or on a time interval?) go through the results and remove duplicates based on the cookie values, IP/UserAgent combinations etc.
I'd assume that not actively blocking multiple votes from same person keeps the usage of highly technical circumvention methods to a minimum and the results are easy to clean.
As a down side, you can't probably show the actual vote counts live on the user interface, or eyebrows will be raised when bunch of votes just happen to go missing.
Although I probably wouldn't do this myself, but look at these cookies, they are pretty hard to get rid of:
http://samy.pl/evercookie/
A different way that I had to approach this problem and fight voting fraud, was to require an email address, then a person could still vote, but the votes wouldn't count until they clicked on a link in the email. This was easier than full on registration, but was still very effective in eliminating most of the fraudulent votes.
If you don't want force users to log, consider this evercookie, but force java script to enable logging!
This evercookie is trivial to block because it is java script based. The attacker would not likely use browser, with curl he could generate tousends of requests. Hovewer such tools have usually poor javascript support.
Mail is even easier to cheat. When you run your own server, you can accept all email addresses, so you will have practically unlimited pool of addresses to use.
Of course, I store all players' ip addresses in mysql and I can check if there is a person with the same ip address before he registers, but then, he can register to my page at school or wherever he wants. So, any suggestions?
The only way that proves particularly effective is to make people pay for accessing your game.
Looking behind the question:
Why do you want to stop the same person registering and playing twice?
What advantage will they have if they do?
If there's no (or only a minimal) advantage then don't waste your time and effort trying to solve a non-problem. Also putting up barriers to something will make some people more determined to break or circumvent them. This could make your problem worse.
If there is an advantage then you need to think of other, more creative, solutions to that problem.
You can't. There is no way to uniquely identify users over the internet. Don't use ip addresses because there could be many people using the same ip, or people using dynamic ip's.
Even if somehow you made them give you a piece of legal identification, you still wouldn't be absolutely sure that they were not registered on the site twice as two different accounts.
I would check the user's IP every time they log onto the game, then log users who come from the same IP and how much they interact. You may find that you get some users from the same IP (ie, roomates, spouses, who play together and are not actually the same person). You may just have to flag these users and monitor their interactions - for example, is there a chat service in the game? If they don't ever talk to each other, they're more than likely the same person, and review on an individual basis.
If its in a webrowser you could bring the information like OS or browser but this even makes it not save but still safer.
It would take the hackers only a little more time and You have to look for the possibility that some people could play on systems with the same OS and browser
The safest thing would be that people on the same IP cannot do things with each other like trading or like in the game PKR (poker game) that you cannot sit on the same table.
An other thing would be wise to do is to use captcha's, its very user unfriendly but it keeps a lot bots out
If it is a browser-based game, Flash cookies are a relatively resilient way to identify a computer. Or have them pay a minimal amount, and identify them by credit card number - that way, it still won't be hard to make multiple account (friends' & family members' cards), but it will be hard to make a lot of them. Depending on your target demographic, it might prohibit potential players from registering, though.
The best approach is probably not worrying much about it and setting the game balance in such a way that progress is proportional to time spent playing (and use a strong captcha to keep bots away). That way, using multiple accounts will offer no advantage.
There are far too many ways to circumvent any restrictions to limit to a single player. FAR too many.
Unless the additional player is causing some sort of problem it is not worth the attempt. You will spend most of your time chasing 'ghosts' instead of concentrating on improving the game and making more money.
IP bans do not work nor flash cookies as a control mechanism either.
Browser fingerprinting does not work either. People can easily use a second browser.
Even UUID's will not work as those too can be spoofed.
And if you actually did manage to discover and implement a working method, the user could simply use a second computer or laptop and what then?
People can also sandbox a browser so as to use the same browser twice thus defeating browser identification.
And then there are virtual machines....
We have an extreme amount of control freaks out there wanting to control every aspect of computing. And the losers are the people who do the computing.
Every tracking issue I ever had I can circumvent easily. Be it UUID's, mac addresses, ip addresses, fingerprinting, etc. And it is very easy to do too.
Best suggestion is to simply watch for any TOU violations and address the problem accordingly.