Registration Attacks

Posted: Tue Jun 14, 2005 2:30 pm

I´m looking for any tips how to prevent registration attacks.
I´was wondering about 15 new registered members at last Saturday. Confused

The day before 11 members.

Our problem is, that we grow to fast.It´s strange but the most of our new members don´t post in the forum, don´t select a language or an avatar. Possible a language problem but it´s also possible that they are not human.

Posted: Tue Jun 14, 2005 2:36 pm

The best way to prevent robot registration is to enable GFX validation during registration.

You could also require administrator validation before approval of registrations which is what I do at my domain.

Finally, I also require users provide a non-free email address during registration. That has helped me keep abuse to a minimum.

I should mention that it is not uncommon to have people register, yet fail to post in forums, or to select a language or an avatar. Keep in mind, most don't need to do the two latter items and many times they register for other reasons, like for access to "registered only" sections.

Hope this helps

Posted: Tue Jun 14, 2005 5:07 pm

Quote:

The best way to prevent robot registration is to enable GFX validation during registration

Thanks for your helpful suggestions.

But how can I add a captchas - GFX in Nuke 6.5 Your Account new user registration ?

The fields are only for nickname, email and password. Thats all.

Posted: Tue Jun 14, 2005 7:10 pm

I don't have any 6.5 code, (7.0 is the earliest version I have worked with) so I'm not really sure.

Maybe someone else that is using 6.5 can answer how to enable the GFX confirmation to the user registration process for 6.5.

I'm assuming that you are using the default Your_Account registration (versus an add-on YA module).

Wish I could be more helpful, but I will look around in the meantime and see what I can find.

If 6.5 has the GFX function as with other Nuke versions, it would merely be a matter of adding the input element call in the registration <form>.

For example: In your modules/Your_Account/index.php you'd have something like this:

Code:

         if (extension_loaded("gd") AND ($gfx_chk == 2 OR $gfx_chk == 4 OR $gfx_chk == 5 OR $gfx_chk == 7)) {


            echo "<tr><td colspan='2'>"._SECURITYCODE.": <img src='?gfx=gfx&random_num=$random_num' border='1' alt='"._SECURITYCODE."' title='"._SECURITYCODE."'></td></tr>\n"


            ."<tr><td colspan='2'>"._TYPESECCODE.": <input type=\"text\" NAME=\"gfx_check\" SIZE=\"7\" MAXLENGTH=\"6\"></td></tr>\n"


            ."<input type=\"hidden\" name=\"random_num\" value=\"$random_num\">\n";


         }

immediately after the input:

Code:

."<tr><td>"._PASSWORD.":</td><td><input type=\"password\" name=\"user_password\" size=\"15\" maxlength=\"20\"></td></tr>\n";

and just before the input of the hidden fields (or the submit function).

You'd also need to add:

Code:

         mt_srand ((double)microtime()*1000000);


         $maxran = 1000000;


         $random_num = mt_rand(0, $maxran);

Anywhere after the opening

Code:

   if (!is_user($user)) {

of the function.

If you are using the regular Nuke 6.5 YA module, .zip up the index.php of the module and put it (temporarily) on your website somewhere. Then send me a Private Message with the URL address to it and I'll download it and take a look. If I can fix it, I'll do so and send it back to you.

Hope this helps!

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

Unfortunatley it doesn't help much. The automated attacks still occur because the gfx routine is easily reverse engineered. A true "captchas" would stop it, imo, but I haven't had time to properly implement one. Maybe someone else has?

Posted: Tue Jun 14, 2005 10:27 pm

I must agree that the above isn't the strongest captchas solution in the world, but it is what nuke has now.

My biggest compliant is that the nuke variation isn't very strong image wise, but I should mention that you should watch out for the new CNB_Your Account Version 5.0.0 (coming soon to nuke) which will have a MUCH stronger Captchas capability versus anything else available presently for Nuke.

My Recoded Version of the New CNB_Your Account Version 5.0.0 Administrator Screen For Captchas Security

I don't want to give away the farm (which I would never do anyway) but the above screen shot of the new administration panel defines some of the CNB_YA 5.0.0 capabilities in this regard. The authors have done a lot in this regard (I just recoded everything to be 100% W3C Compliant).

Sorry, I won't share any of the code with anyone, as afterall, this is in alpha testing and this code is guarded at this point. I'd have to cut my fingers off if I were to share anything publically.

I have also been playing with "Gimpy", as well as "Pix" as there are a few algorithms out there that supposedly can beat Gimpy variants which I have added partially to my bastardized version of CNBYA 5.0.0. When I get further into it, I'll be sharing that code back to the CNB Project as well.

I'm also finding that in many cases, Gimpy solutions aren't readable by humans, never mind machines, whereas the Pix solution is very elegant by not using any recognizable "data" that could be interpreted.

After all, seeing a picture of an elephant doesn't give anything for a machine to filter, but knowing how to spell what is on the picture could create a problem for some people.... (Yeah, there's always a downside).

I think that CNB_YA 5.0.0 addresses this head-on by letting the administrator decide how tough they want the Captchas to be, but I'm sure this too will further evolve over time. I merely wanted to point out what is in the works now. I suspect before this is done, we'll also integrate a multi-font solution (multiple fonts within each image) which will make it even harder to read.

Anyway, just my 2 cents and a heads-up. I was hoping the above code at least was a start to addressing the user's issue, but if not... at least know others are working on this for CNBYA 5.0!

Smile

Steph

Posted: Tue Jun 14, 2005 10:37 pm

Looks nice, but the answer is not in the graphics, it's in the security code algorithm. It's predictable. It's hackable. That's what needs to change.

Posted: Tue Jun 14, 2005 10:38 pm

Do you mean MD5 Encryption (which is kind of a must anyway)? Or having it as a CGI.... etc...

I know that a lot of bots are now using image scan functions to decode and thus, I think that this is still an important aspect, but as I see it, if it were encrypted, (given the time to response issue of having it expire) would address a bots ability to beat the algorithm. If it is truly hidden and you only have 15 seconds and it is encrypted, I say.... good luck to the bots. Smile

Posted: Tue Jun 14, 2005 10:59 pm

No. The security code number reference in the img tag. There are scripts that can take the 2004 and run it through the gfx() function and extract the securty code. It's 100% predictable if the $sitekey hasn't been changed. If the $sitekey has been changed then it's pretty much impossible. But, I have been told that there is another way to bypass it and I believe it because I get mass lottery signups all the time. However, I have code I put in that traps about 98% of them Smile

Code:

http://localhost/ravenphpscripts/modules.php?name=Your_Account&op=gfx&random_num=2004

Posted: Tue Jun 14, 2005 11:15 pm

I hadn't heard of this problem at all. But I'm also not quite sure I understand exactly what you are saying either in reference to any bot being able to beat the algorithm. The whole "2004" issue is unknown to me, as are mass lottery signups. I just haven't seen them on my domains, but keep in mind, I have also GoogleTapped all of my GFX functions and images which the bots tend to hate for some reason.

Where exactly are you putting that code and what exactly is it doing?

Thanks

Posted: Wed Jun 15, 2005 1:17 am

I think I got it Smile

- Try registering as a new user. Then let me know when I can delete the new username Groovy