0

I'm currently working on my Referral System, but I have a problem with protecting it of frauds. Okay, here's how it works for now:

  • user registers and activate it's account
  • user now have access to the control panel and there is it's uniqe link in following format: domain.tld/ref/12345
  • when someone other click to user's link, he or she must to click a specific button to confirm that is not some kind of fraud (like "click here, you'll get $100" or something)
  • system writes visitor's IP in a database and some data to cookies to prevent re-pressing the button. User now have +1 point.

But, the problem is that visitor can change it's IP, clear cookies and hit button again. It takes a few seconds, and that's not OK, that's cheating.

How to prevent it? Is there some trick to get some unique computer ID or something can't be changed that easy?

Pixel
  • 104
  • 1
  • 10
  • If a computer changes it's IP and clears it's cookies, as a server, you have no way of identifying it as the old computer. You can use things like facebook connect, or another single-sign-on service, but even those are prone to people have multiple accounts. – DanRedux Apr 25 '12 at 21:29
  • 2
    Referrals usually require signups, not just clicks – Musa Apr 25 '12 at 21:32

4 Answers4

1

Really the only options are to tie the process to something which is not so easily manipulated by the user - super cookies, browser fingerprints, OpenID, Email addresses and telephome numbers (the latter 2 using some sort of validaton step before a vote is counted)

symcbean
  • 47,736
  • 6
  • 59
  • 94
0

The only way you can be certain a referred party does not reuse a referral code is for the original user to send different one-time-use-only referral URLs to each person. Once the code has been used, it is flagged as such in (or removed entirely from) your database so that it can not be used again.

How you prevent the original user from sending multiple links out to the same person is another matter - and not an easy one to resolve.

Who do you perceive to be the threat?

eggyal
  • 122,705
  • 18
  • 212
  • 237
  • The threat are registered users, not visitors. User can ask a friend to click button 100 times and friend will do that. So, that's the problem, I want to prevent it. – Pixel Apr 25 '12 at 21:37
  • @Dzonny: you can make it more difficult for a layperson, but there's very little you can do to make it difficult for anyone with a little bit of knowledge without introducing hurdles that would almost certainly discourage any users from using your system altogether (such as requiring them to appear somewhere in person for fingerprint verification). The most common approach is to require new signups to verify their email address, but that completely overlooks how trivially easy it is to obtain additional/disposable email addresses. – eggyal Apr 25 '12 at 21:39
0

Although it's certainly not 100% accurate, you can still fingerprint visitors using for example a combination of their ip, browser user agent, and with some javascript you can even go for screen size or installed fonts. Using these pieces of information you can set up a system where you save the fingerprints in datatable and in the same record you store the session id (from the cookie). Now when a new visitor arrives you can test their fingerprint against the db of recent fingerprints with different visitor ids. If you find a large number of matching fingerprints (you define the threshold) with different sessions then you can alert for the possibility of fraud.

Cheers

smassey
  • 5,875
  • 24
  • 37
  • The question explicitly asks about defeating situations where the referrer changes their IP; in such situations, your proposed fingerprint would likely result in too many collisions/false positives. – eggyal Apr 27 '12 at 06:54
0

How about storing the link with with the user when they navigate to the link. then in the database you will have the link and if the users has already been to the link then deny them. Seems like it could work then you wouldn't have to worry about the cookies etc...

jjlm
  • 38
  • 6