Preventing abuse to an invite system

Question

recently I helped some friends ship an invite system in their website that works like this: A user creates an account, we send a verification email and when he verifies the e-mail he gets one free credit to spend on the website. In addition to that, he has personalized links he can share on social networks or via e-mail and when people register using this link (e-mail verified accounts again) he gets one credit per invite. Much like the invite system on thefancy.com or any other reward driven invite system on the web.

Lately we see elevated rates of fake user account which probably are automated. The registration page features a CAPTCHA but we're aware this can be bypassed. We also see elevated rates of users creating disposable email addresses to create accounts following specific invite links thus crediting one legit users that onwards uses the free credits he earns.

I am looking for an automated way to prevent such kind of abuse. I currently investigating putting rate limits on invites/registrations that come from the same ip address but this system itself has it own flaws.

Any other production tested ideas?

Thank you

Edit: I've also proposed 2 factor registration via SMS but was turned down due to budget shortage.

Supernova

Are these presumed fake accounts are still being verified? – Niagara

Yes they need to verify via e-mail to earn their one free credit and send the one free credit to the unique link's owner. – Supernova

I'd suggest disallowing any email domains that are used by 5 minute mail sites. – Carcinoma

I've inspected some of the e-mails addresses. It seems quite of the suspected ones also come from GMail and not only from disposable mail providers. Some sort of <md5_hash>@gmail.com type. – Supernova

How are you verifying the email addresses? If the link in the email can be generated programatically, there's a chance that they are simply computing what the verification link should look like and submitting it; that would allow them to generate arbitrary accounts without having to own the address. – Unisexual

The verification link is a hash generated using the username, the e-mail and the timestamp so no... I guess it can't be guessed – Supernova

Are the components of the hash (specifically the timestamp) available to the user at the time of registration? Or, alternatively, do you check that the timestamp matches the one that you sent out exactly? – Unisexual

Answer 1

It seems you need to require more than just a verified email address before a user can send invites, ideally something that shows the user has participated in your site in some way. Without knowing what your site is it's hard to give specifics, but the StackOverflow equivalent would be requiring users to have at least X reputation before they can invite others. If you're running a forum you could require that they've made at least X posts.

I'd also suggest a small time limit before new accounts can invite - e.g. they have to have been a member for at least X days. This complicates automated invites somewhat.

Isidraisidro

Though I agree, it's tough to keep legitimate users engaged when they have to wait to perform a site action. As long as there's more to the site than an invite tree, it should be fine though. – Niagara

Answer 2

An extremely simple method that I have used before is to have an additional input in the registration form that is hidden using CSS (i.e. has display:none). Most form bots will fill this field in whereas humans will not (because it is not visible). In your server-side code you can then just reject any POST with the input populated.

Simple, but I've found it to be very effective!

Durware

Same goes with javascript-generated fields, time lapse comparison from form display to form submit, and other techniques to verify a client is participating. But sadly because bots are programmed, most people who write them also know the countermeasures. – Niagara

Answer 3

A few ideas:

• Ban use of emails like 'mailinator'.
• Place a delay on the referral reward, allowing you to extend fraud detection time period, giving you more time to detect bogus accounts and respond accordingly.
• Require the referred user to create a revenue generating transaction before you give out any referral rewards (I know that might not be a shift you can make) - possibly in turn increasing the reward to account for the inconvenience to the referrer (you should be saving money through decreased fraud so not a hard sell).
• Machine learning. Ongoing observations and tuning with your fraud detection. The more data you have the better you will be able to identify these cases. (IP addresses as you mention.) Shipping / billing info even more telling if it applies - beware adjacent PO boxes.

Shawanda

Answer 4

Add a CAPTCHA test to the confirmation page. I would be wondering if your CAPTCHA is sturdy enough if it is getting bypassed somehow. You might consider using the (hateful) reCaptcha which seems popular. A CAPTCHA on the confirmation page would reduce the risk that a 'bot is submitting the confirmation page. In other words, it would implement the idea of client interaction with the site after registration. A similar method would be to ask for the registrant's password.

Ropedancer

What would another CAPTCHA in the confirmation page provide to the security? We already use reCAPTCHA but it's relatively easy to crack too with 99% accuracy. – Supernova