Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

marked as duplicate by AJ Henderson, Scott Pack, Ninefingers, Iszi, this.josh Feb 5 '13 at 23:47

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
This is covered in my answer here: security.stackexchange.com/questions/29571/… –  David Stratton Feb 5 '13 at 2:43

5 Answers 5

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.

share|improve this answer
    
Please elaborate on the second method. What is a token cookie? –  Celeritas Feb 5 '13 at 18:15
  1. Count how long they stay on the page. If too soon mark as spam
  2. Add your own fields
  3. Use a Puzzle box
  4. Entirely change the process of registration so it's different then the default way like how forum spam bots work.
share|improve this answer

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.

share|improve this answer
    
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 Feb 5 '13 at 10:17
    
@F.Hauri - Yes of course. However, OP asked about possible ways to prevent robotic user registrations and alternatives to CAPTCHAs, 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. –  Noordung Feb 5 '13 at 15:56

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)

share|improve this answer
    
A bot could do OCR! At all I could'nt tell the answer (error token is "*3\*8*") :-( –  F. Hauri Feb 5 '13 at 7: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 5 '13 at 13:54

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

  1. 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

  2. Spam check against required textDesc, with one or many anti-spam tools.

  3. 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.

  4. 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).

  5. 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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.