470,602 Members | 1,355 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,602 developers. It's quick & easy.

cookie related accounts

Hi ,

Say if someone is abusing our webservices by creating several user id's, So how can we stop them ?

I believe comparing two account created on the same machine,network,cookie or IP is the solution for that.

Say, if user A logged in and later User B logged in to the same computer then i need to be able to find them out, by means of COOKIE .

Need good suggestions and ideas to accomplish this.

Aug 5 '10 #1
19 3260
1,654 Expert 1GB
You can set cookies, but it will work as long as the user doesn't delete them or send a request from a different browser next time.

IP address doesn't remain the same always and also there can be more than one machines working behind one IP address (in case machines are behind a router). But you can maintain a list of blacklisted IP addresses from where you see request coming multiple times.
Aug 5 '10 #2
My question was how to relate two user's ?
In sense of cookie, ip ?
For the thing cookie i am bit confused how to do ?
That is why i am asking for suggestions.
Aug 5 '10 #3
1,168 Expert 1GB
What you are trying to do is near impossible. As mentioned, some people have dynamic IP addresses, so while it may look like one user several accounts, it's actually just lots of people with over lapping dynamic IP ranges.

Cookies are easily bypassed, but work in a similar way to a session:
Expand|Select|Wrap|Line Numbers
  1. $_COOKIE['user_id'] = 12;
And then you can check it:
Expand|Select|Wrap|Line Numbers
  1. if ($_COOKIE['user_id']!=12) {...}
What does your site do/provide where users may want to have more than one account? A game?
Aug 5 '10 #4
Ok, here is the situation, i offer only one free account and it is quite possible that a fraud person can exploit our system and can create more than one account ? How can i catch him up?
Aug 6 '10 #5
1,168 Expert 1GB
What does your software/service do? Is it a game or business or what?
Aug 6 '10 #6
We have a gaming portal, we offer free membership only for one user for 30 days and after that have to go for paid one. Suggestion required for implementing the stuff. Even how to catch the network Cookie, IP etc. As we will manually reveiw the stuff.
Aug 6 '10 #7
make it mandatory for all your users to register their credit cards before they begin the trial bersion of your portal. It will discourage the "fraudsters". If they like the trial version, they can go ahead and purchase it or walk away if they don't. Apple does it with their software products.
Aug 7 '10 #8
I have done that, still we receive fraud credit card transactions so we use maxmind for that! But still i am finding a strong solution for my problem. And credit card is also of no -use if you have four credit cards, then you can register four different account, Which i do not want on my site to happen. As far as Jyoti Ballabh told me to do i am quite confused to understand the logic.
Aug 7 '10 #9
What's the harm if someone having four credit cards registers with all of them using different usernames? You are running a gaming portal and revenue generation is your foremost aim like any business. Don't worry about what JB said, the whole concept of security token was new to me as well but I think you apply that when you expect a huge turn out or traffic for your site.
Aug 7 '10 #10
iohos, I agree with you, here i my brief problem: If i would pose Credit card for registration i would loose conversion rates, cos not everyone would like to post a credit card at the very begining! Esp when website is not so popular one. I just need each member should have only one account! Not more than one ! Now how to achieve that !
Aug 7 '10 #11
Why don't you post the url of your portal? It'll give us all a better understanding of what you are looking for. If you are afraid that asking for the credit card info may diminish your conversion rate then don't give into the phobia of single user- multiple usernames strategy. It's the risk you will have to take. Besides, if your gaming portal or game is so addictive to entice an individual to such fraudulent means, then I am sure it would have the mettle to fetch in many genuine users as well who actually purchase it. I find it weird when despite being a start-up in this field you insist on maintaining this strict policy. Why don't you just put up a counter for your site which keeps a track of the traffic the site creates and displays the number every time someone logs in. This will give a newcomer to the site a fair idea about how popular the site is and this is like a positive reinforcement reaction.
Aug 7 '10 #12
Why don't you post the url of your portal?

iohos's : As far as i understand you mean to say that i should make my users know that i am tightening the security by posting the URL here.
The suggestions gave by you are not as what i wanted for ?

Aug 8 '10 #13
Okay, as far as i am not clear on my question!
So here is a one line query : How to trace users with multiple accounts ? Already done with googling! Any ideas ?
Aug 8 '10 #14
5,058 Expert 4TB
The bottom line is, you can not reliably prevent users from registering multiple times. You can try to make it difficult by logging IPs, using tokens or credit card info, but none of that will hold up if users really want to bypass it. There just isn't enough information available to make it practical. (Not enough "solid" information, anyways.)

This is why many services that offer both free and payed accounts limit the feature set of the free accounts, rather than offer an unlimited account on a timer.

Your choices are basically: try to prevent multiple registrations with the ideas that have already been posted here, and accept that you won't be able to prevent all of them; or try something different, like what I posted above.
Aug 8 '10 #15
Hi Atli,

The bottomline is there is no one here i got a perfect reply to my question. Hope i get it from some other Board.
So i am not choosing any answer. I hope that you will also delete my post.

Aug 9 '10 #16
5,058 Expert 4TB
I'm afraid the perfect answer you are looking for doesn't exist. Like I said before, there simply isn't enough information available to us to be able to reliably identify users like that.

Good luck though. I hope you find an answer you are happy with somewhere.

And no, I won't delete this thread. I'll leave it up here for anybody searching for similar answers.
Aug 9 '10 #17
1,168 Expert 1GB
Zahir86, when you believe you have found "the answer" come back here, and I am sure we will show you that there is a way around it. Unfortunately, people are smarter at getting around security than implementing it. I have tried to do what you're trying to do for a long time, on many boards. The perfect solution does not exist.
The best way I believe has already been mentioned, which is using credit cards. This is more of a deterant to people making multiple accounts as they need multiple credit cards. The problem is, it means that you will lose customers because they would prefer not to give you CC details until they have tried it.

As Atli said, good luck and I hope you find satisfaction somewhere else, but I would like to say that Bytes has the best team I have seen on any board anywhere on these topics, and that's why I am here!
Aug 10 '10 #18
1,654 Expert 1GB
Zahir, considering the current technologies, I don't think you would be able to make a perfectly secure system for the given scenario. More important you should consider is to make an "idiot proof" system.

And in case you found a way to make it perfectly secure, do me a favour to share it here.
Aug 11 '10 #19
213 128KB

The question was, "Say if someone is abusing our webservices by creating several user id's, So how can we stop them ?"

Thank you for responding, "This is why many services that offer both free and payed accounts limit the feature set of the free accounts, rather than offer an unlimited account on a timer."

I found this post years later as you said, "And no, I won't delete this thread. I'll leave it up here for anybody searching for similar answers."

My response to
"if someone is abusing our webservices", combined with "We have a gaming portal":
If you must supply some free use, then do that separately from your full game, on a different server, via a different web server host. Split the two completely apart. Two different dot com's. Two different hosts. Two different accounts paid for by two different companies. Split them apart completely.

Do that with a very limited version of the game which has very limited play, and let them play that very limited version until they (by themselves) (on their own) decide to either pay to play the full version of the game, or quit. Maybe, strip parts out of the full game and place notices that tell them "This is only available in the paid version." Put in a lot of these and they will probably get tired of the free game and pay or move on. If they are aggressively flooding any of your sites then turn them over to the NWCCC (nw3c.org). It will be simpler for you when dealing with the NWCCC if you have split the two games (free and paid) completely apart.

You could even have a notice, that for free users if they play the free version and abuse the service, they may be turned over to the NWCCC. So, those types of people can see that if they have a fit and get aggressive then they might have more than they can handle, thus a good reason to not get aggressive.

I disagree with
"More important [than to make a perfectly secure system] you should consider is to make an "idiot proof" system." For what you described, "security is first".
Dec 24 '20 #20

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

6 posts views Thread by Mark | last post: by
5 posts views Thread by Greg Cyrus | last post: by
2 posts views Thread by Jeff Bowman | last post: by
1 post views Thread by abcd | last post: by
reply views Thread by dmbkiwi | last post: by
reply views Thread by Arpan | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.