Some interesting reads about ReCaptcha and Captcha failures in general.

I've read through all the messages in this thread and still have a couple of questions.

First, an observation. It shows me the importance of monitoring xoops.org and it makes me wonder if we need an alert system that people can sign up for. Perhaps a special forum topic to which only admins can post but to which users like me can check the appropriate notify box.

The general consensus seems to be that the XOOPS captcha has been cracked using OCR techniques. A couple of things still bother me. Normally I should get a notification email telling me of any registration on my site. I definitely did not get the notification for the two "google.com" registrations I've received. Do we know how that was by-passed? It makes me wonder whether setting the requirement for admin approval of registrations (which I have done) will be effective. Time will tell, but I will have to occasionally for for these registrations to check.

I also have a couple of required fields that appear on the second page of the registration process. Those were not filled in but all the fields in the first registration page were filled with random characters. I know that if one aborts the registration process after accepting only the first form, a user is still created. Presumably that happened here. Is there a way to require that second page be filled in? I suppose it wouldn't take much for a bot programmer to accommodate that need. I also wonder about the hidden field idea that was mentioned in the thread that ghia pointed us to. That would have to appear on the first registration form and, if completed, the registration attempt would be rejected. It was said that it would not defeat massive attacks but it might defeat random bots trying to register on any and all XOOPS sites.

That raises another question. Are these registrations aimed specifically at XOOPS sites or sites with registration procedures in general? Maybe it's an unfortunate testimony to the growing popularity of xoops.

Finally, I hope someone can let us know how the process of adding reCaptcha, as outlined by ghia, works for them. I do plan to try to implement it on my test site, which is a copy of my live site on a different domain. I'll report back, hopefully later today, if someone doesn't beat me to it.

barryC

Well, you might want to try this. Change the 'oursite' value to your own and pop it right at the beginning of register.php. It stops direct access of the file if the referer is blank, or doesn't include your website.

It goes without saying to make a backup first.



I could have used a redirect, e.g. back to index.php, but I think sending a 403 error may help dissuade repeated attacks.

I tested it on a XOOPS 2.0.18.2 site and I could access the file from any page and the registration worked properly using the Frameworks captcha. I haven't tested it on 2.3 or later so it may not be compatible.

Of course, if it fails to stop the bot, then it's back to the drawing board!

Quote:OK, but then do not give away the clue.
Do simply exit(); instead of the die.

$oursite could be replaced by XOOPS_URL, making it a configurationless hack.

The same could/should be applied to /class/captcha/image/scripts/image.php

Quote:

Good ideas

I found that accessing img.php from outside of the captcha gave a blank page, but yes, a good idea to add to that file too.

Based on barryc's log this *should* provide at least a temporary fix. Any feedback would obviously be useful.

For the record, I have seen one more spurious registration with the Google URL since incorporating reCaptcha. It occurred on 12/6/09. It appears that reCaptcha does not completely prevent these registrations. I wonder if the robot is really using OCR to by-pass the code entry or if this one registration simply got lucky and guessed the two words required by reCaptcha, perhaps using a brute force method. Again, I could find that log entry if someone would like to look at it.

I had not implemented the hack suggested by peekay. ghia suggested a change and I'm not sure exactly how to incorporate that. Would one of you post the complete code with that change?

barryc

Did you try to add step in registration in frofile module?
1st step - put login name and password
2nd step - put your email
3rd step additional fields that extends registration (ICQ, country, city .... whatever)


And some bot prevention.

This hack will break the self activation process for new users.

I solved my bots problem!!! What I did was integrate the IP trap I found for OSCommerce here: http://www.linuxuk.co.uk/ip-trap-p-30.html?osCsid=243b86d01d2ef456f3594bd4f70c1686

I replaced the default index.html file in most of my folders and system folders with the index.php file that comes in the IP trap "personal" folder, and did the same in all of my directories listed in robots.txt, added the directories and files in the IP trap robots.txt to the bottom of my existing XOOPS robots.txt, edited the IP trap .php files included to match my XOOPS site and then added one line to index.php and register.php that the INSTRUCTIONS included with IP trap state that you should add to application_top.php in OSCommerce.

I also added my own server IP to the whitelist file. (Not sure if it was important but I did it anyway.)

Pretty much you can just follow the installation instructions and just take the few extra steps I took and it will work.

I haven't had a single bot problem since I did this. It automatically bans bots from the site. I'm sure someone could re-release this with custom instructions for Xoops.... I haven't had a single problem with it, and it hasn't caused any module problems so far. It just bans bots scanning your XOOPS directories.

OOPS!!! I forgot. I had to change that line of code in the instructions to:
require XOOPS_ROOT_PATH.'/includes/secret.php';

I put it right in the main index.php XOOPS file after the line:
include "mainfile.php";

For OSC the line looked like this: require(DIR_WS_INCLUDES . 'secret.php');

ALSO make sure you edit the index.php in the personal folder with your own URL before using it to replace the index.html files.