Good ways to prevent spammers from registering

Question

Possible Duplicate:
Is there a true alternative to using CAPTCHA images?

Since everyone hates captchas what are good alternatives? I'm looking to prevent the automated creation of accounts on a website but I'm also concerned about people. If the registration is too easy there would be nothing stopping people from creating accounts haphazardly but at the same time the registration process should be easy. What to do?

This is covered in my answer here: http://security.stackexchange.com/questions/29571/is-there-a-true-alternative-to-using-captcha-images/29582#29582 — David Stratton, Feb 05 '13 at 02:43

score 4 · Answer 1 · answered Feb 05 '13 at 08:36

4

The simplest way is to add a hidden input to your form, and refuse to submit the form is that input is filled.

Another efficient way to do this is to generate a token cookie, store its value inside a hidden input, and compare both of form submission. Since most spambot can't handle JS, it won't work for them.

answered Feb 05 '13 at 08:36

fbnlsr

41
1

Please elaborate on the second method. What is a token cookie? – Celeritas Feb 05 '13 at 18:15

score 3 · Answer 2 · answered Feb 05 '13 at 01:10

3

Count how long they stay on the page. If too soon mark as spam
Add your own fields
Use a Puzzle box
Entirely change the process of registration so it's different then the default way like how forum spam bots work.

answered Feb 05 '13 at 01:10

Travis Thompson

539
1
5
9

TildalWave · Answer 3 · 2013-02-05T02:27:30.150

I'm of firm belief that the best way to both control spammers as well as maintain high registration percentage is to simply reverse the process and require registration (or log-in, if user's already registered but not signed-in) details once user already submitted whatever he/she wanted to contribute to your website. Two reasons why:

User already went through the trouble of typing whatever he/she wanted to and is thereof more likely to complete the registration process, and
You already have insight into contents users wanted to submit. These posts can be run through spam filters and checked for unwanted contents a lot easier than maintaining any blacklists (public or private).

People can argue that you're tricking your user-base into registering just to post a comment or such, but that can be easily controlled with end-user notifications, if needs be. It's not that difficult to implement either. You can either do it the same way you'd register a new member before email verification (write to DB but mark inactive until registration/log-in is complete), or carry the input fields forward through the registration process in hidden form fields. If we're not talking about content heavy submissions, then the second option is the easier one.

Of course, once a user is discovered to have been trying to submit spam messages, you should immediately flag user's IP address (and tracking cookie, if any) as unwelcome in your DB and check against it each time they try to submit anything new, or even better - completely disable user input to those IPs so they can't flood your web server with too many requests. These flags probably shouldn't be permanent (unless you're really confident in the way your supporting code works) and should be regularly checked to see if your automated spam filter implementation needs corrections.

Flagging implie timeout, while IPs may be dynamic. At all, flagging an IP could lead such grouped use of IP (like cybercafe, for sample) in a DOS state. — F. Hauri - Give Up GitHub, Feb 05 '13 at 10:17
@F.Hauri - Yes of course. However, OP asked about possible ways to prevent robotic user registrations and alternatives to `CAPTCHA`s, and that implies checking form submissions on the web application level, which would be only one among many possible protection schemes, mainly to protect against `SPAM`. `DoS` attacks can't really be handled at the web application level, as attacker still succeeds in loading all the necessary web server response resources as easy as with `HTTP FLOOD`-ing, thus it needs to be handled at lower levels. There's plenty of threads on IT.sec for that. — TildalWave, Feb 05 '13 at 15:56

score 0 · Answer 4 · answered Feb 05 '13 at 01:39

0

add a challenge, something like a text box input, with question like:

What is the answer of *3\*8* ?

you can display the question as an image, generated by php-gd (if you are using php)

answered Feb 05 '13 at 01:39

sharp12345

1,969
3
13
23

A bot could do OCR! At all I could'nt tell the answer (`error token is "*3\*8*"`) :-( – F. Hauri - Give Up GitHub Feb 05 '13 at 07:29
@F.Hauri Obviously, bots can do OCR, but this is less annoying to the users than doing a captcha which is hard to read sometimes. – sharp12345 Feb 05 '13 at 13:54

score 0 · Answer 5 · edited Mar 17 '17 at 13:14

Unlike a chain, more long it is, less are the chances for a spammer (bot) to pass through:

Build a registration form containing nick, full name, email, password, (pass verif) and a brief description as textDesc.

1b - use captcha if you believe on it... see my opinion about captchas
Spam check against required textDesc, with one or many anti-spam tools.
For paranoid only: Greylisting all suspect email to waiting for (quick check) human ( postmaster or sitemaster by he could by called master ;-) verification before next step.
E-Mail address verification: Only the email as to be used, ( with YOUR domain name and a hash of registration ID for validation ), in order to prevent the use of full name or nick to send spam to fake expeditor (real spam destinataire).
Registering new user after verification of hash and password verification. If validation request not recieved after some time (for ex: 4 days -> smtp limit) drop registration request.

Good ways to prevent spammers from registering

5 Answers5

Linked

Related