[captcha] Registration Security code

[David]

Even though captchas do not block everyone, they block many casual script kiddies.  As soon as we up the ammount of time involved in flooding a board, it decreases the number of people willing to try.

I fully support captchas being added to SMF, after seeing there use on a site that does well over 1000 requests per second.

[[Unknown]]

Even though captchas do not block everyone, they block many casual script kiddies.  As soon as we up the ammount of time involved in flooding a board, it decreases the number of people willing to try.

I fully support captchas being added to SMF, after seeing there use on a site that does well over 1000 requests per second.

I just added more portection to registration, as requested.  Didn't take captchas.

And, again, there can be server configuration problems that will make them not work.  So good bye to ANY registrations.

-[Unknown]

[koder]

Just a couple points:

1.  Registration spamming is not and will never be a question of one person from one ip, but of thousands of collectively-linked drones from thousands of unique IPs.  If you are not familiar with the concept of dDOS (Distributed Denial of Service), then you've been missing out on news of some of the largest attacks against some of the biggest sites with the biggest pipes on the internet.  The danger of mass registrations is not from one person, but from at least 1000+ pseudo-persons.  It becomes increasingly difficult to weed out or otherwise tell the difference between 1000 different ips with different length and pattern usernames and different emails from different domains from different countries... from just a normal user.
      One might argue, however, that if 1000 people are attacking your site you're screwed anyway; however, it's easy to filter out fake traffic versus real traffic router-side during an attack (or simply disable areas of a site).  It's quite another to have to go back into a database that's already filled with thousands of fake members, and thousands of spam topics upon those--taking up gigabytes of disk space-- and effectively filter it back out.  Invariably, one must find a backup database copy (if there even is a recent one), and restore old, outdated information over what would have been new, up-to-date information, or just remove all new registrations after a certain timestamp.

2.  Implementing OCR / Captcha technology in SMF would never interfere with its functionality if done correctly.  By default, simply disable it for new installations.  If users or their hosting companies have correctly-compiled versions of php with GD[2] installed, then a function can be added to enable the option, if they so desire (just like a user can choose whether or not to dynamically resize off-site avatars).

3.  OCR isn't just to make things look pretty; moreover, in almost any case, simple logic to prevent registration spamming is insufficient-- particularly code that scales.  It's possible to add global regflood protection based on the site size (for example, a small site isn't going to have 1000 registrations within 1 minute, most likely), however, even after the 'n' number within the 's' seconds ratio has been tripped, there are most likely already 'n' registrations and who knows now many spam topics.  Additionally, what if the attacker is patient, and decides not to attack your site all at once, but slowly register thousands upon thousands of drones over the course of one month; then, all at once, reconnects them all to post topic upon topic.

Yahoo uses it.  Hotmail/MSN uses it.  Egold uses it.  If OCR technology was just to make things look pretty, I highly doubt that so many high-end companies plagued with automated registrations would waste the valuable memory and CPU to perform bulk-scale image de- and re-compression operations on-the-fly; at least, not when those same resources could be diverted to something more ambitous.

I am most likely just going to code this in on my own if it lacks the support from others, but I see it as an invaluable feature for anyone who might ever potentially have some ex-packet kiddie sic his new-found toy drones on your site for banning him.

"Respectfully, I dissent."

[[Unknown]]

Just a couple points:

1.  Registration spamming is not and will never be a question of one person from one ip, but of thousands of collectively-linked drones from thousands of unique IPs.  If you are not familiar with the concept of dDOS (Distributed Denial of Service), then you've been missing out on news of some of the largest attacks against some of the biggest sites with the biggest pipes on the internet.  The danger of mass registrations is not from one person, but from at least 1000+ pseudo-persons.  It becomes increasingly difficult to weed out or otherwise tell the difference between 1000 different ips with different length and pattern usernames and different emails from different domains from different countries... from just a normal user.

And this will take down the server, not register a billion accounts.  The effects of DDoS attacks are much more pervasive than a few thousand registrations, which are relatively easy for anyone running that high profile a site to clean up.

One might argue, however, that if 1000 people are attacking your site you're screwed anyway; however, it's easy to filter out fake traffic versus real traffic router-side during an attack (or simply disable areas of a site).  It's quite another to have to go back into a database that's already filled with thousands of fake members, and thousands of spam topics upon those--taking up gigabytes of disk space-- and effectively filter it back out.  Invariably, one must find a backup database copy (if there even is a recent one), and restore old, outdated information over what would have been new, up-to-date information, or just remove all new registrations after a certain timestamp.

Why?

DELETE FROM smf_members
WHERE dateRegistered = 'when it happened'
   AND lastLogin = 0;

You might lose a person or two, but that'll certainly be the least of your other (much harder to solve) problems.

2.  Implementing OCR / Captcha technology in SMF would never interfere with its functionality if done correctly.  By default, simply disable it for new installations.  If users or their hosting companies have correctly-compiled versions of php with GD[2] installed, then a function can be added to enable the option, if they so desire (just like a user can choose whether or not to dynamically resize off-site avatars).

Wrong.  People WILL turn it on, and people WILL not check to see if it works.  I don't like building red buttons that say "don't push me" on them into the software.  If it breaks for most people, it's a mod plain and simple.

3.  OCR isn't just to make things look pretty; moreover, in almost any case, simple logic to prevent registration spamming is insufficient-- particularly code that scales.  It's possible to add global regflood protection based on the site size (for example, a small site isn't going to have 1000 registrations within 1 minute, most likely), however, even after the 'n' number within the 's' seconds ratio has been tripped, there are most likely already 'n' registrations and who knows now many spam topics.  Additionally, what if the attacker is patient, and decides not to attack your site all at once, but slowly register thousands upon thousands of drones over the course of one month; then, all at once, reconnects them all to post topic upon topic.

I suggest you see a psychologist.  You are paranoid.  Find me someone who has the resources *and* the immaturity to register 1000 accounts, activitate the emails for all of them (and they can't be all the same domains/automatic, or that could be banned in your over-time scenario) and activate them all at once.  If you have enemies that can automate that so easily, captchas won't do you a spot of good.  I bet you sleep with a gun under your pillow too, huh?

Read: captchas are just like passwords.  To brute forcing, they're another layer but that's all they are.  People act as if they are a wall made of the finest steel or something... which is dilluted, at best.  Anyone who can do the things you speak of, over time, as you suggest... well, I'd be more worried about the administrator's passwords, captchas or no captchas.

Seriously, if you run a site that needs this, you can install a mod.  You had to buy your gun, didn't you?  You weren't born with it... apparently your DNA doesn't think it's a necessary feature everyone needs.

-[Unknown]

[koder]

Hmm, don't see a psychologist (I'm working for my masters in it, though), but how did you know about the gun?  It's really for the samurai henchmen that come during the night to tell me things.

Speaking of GD, GD1 is actually available on many of not most commercial webhosts' installations of php.  It-- if not gd2-- is also bundled with all of the major control panels (plesk, ensim, cpanel).  Every webhost I've ever seen compiles-in GD or Imagemagick (for fear of having to recompile due to excessive requests to enable it).  Granted, it along with MySQL support are not by-default compiled into PHP, but just like MySQL many hosts use it.  And either way, we've gone over this-- you already have features in the admin control panel that use GD (if a person supports it):  Settings -> Avatar -> If the avatar is too large... -> Download and resize it (requires GD module).  That's a big red button imo *shrug*

Granted the first half could be considered paranoid, however, when you're mentioning captchas in reference to brute forcing, remember:  each captcha token/sequence can only be tried once, and then it is replaced with a new token on each subsequent attempt-- successful or not.  The reason Yahoo! uses it with locked accounts (accounts that have exceeded n of bad passwd attempts in x time) is because brute force attacks can no longer work at the time the OCR kicks in.  Even a bad password attempt kills the captcha sequence for that given try and generates another for the next login attempt, thus effectively removing the ability to effectively brute-force a password without a person there entering each attempt's captcha code OR software that does really good guesses on a 1:10,000 probability, 5 digit, random, base-10 number that rotates with every page access-- the only records of which remain hidden in server-side $_SESSION variables and in a human-only readable image.

It's something to think about *shrug*.  I mean, the chances of success anyway in a brute-force attack are slim, but this would be a pretty effective deterrant from someone thinking "well, I might as well try."  And trust me, there are _plenty_ of immature people who have the resources to pull this off.  Even I used to be a "l33t hax0r" back in the day.   Just think about all the other 14 year old packet kiddies who have nothing better to do than play Quake 3 and eat Funions after infecting their computer labs at school with home-brewed, drone-creating vb code.

Anyway, I don't mean to keep beating a dead horse if you're really committed to shaking your head vehemently and not doing this, but it seems to me several other forum scripts eventually ended up integrating this in some form after repeated requests from their users (particularly invisionboard).

Thanks for the consideration, though

... and don't tell anyone about the gun. 

[[Unknown]]

Hmm, don't see a psychologist (I'm working for my masters in it, though), but how did you know about the gun?  It's really for the samurai henchmen that come during the night to tell me things.

Heh, heh... see, I thought you'd know I was joking.  Funy enough, someone actually complained to me about saying that!

Speaking of GD, GD1 is actually available on many of not most commercial webhosts' installations of php.  It-- if not gd2-- is also bundled with all of the major control panels (plesk, ensim, cpanel).  Every webhost I've ever seen compiles-in GD or Imagemagick (for fear of having to recompile due to excessive requests to enable it).

I've seen a lot of web hosts, and as importantly, test servers set up by novices.  It's mad mojo to lose the prospective user on the testing, even if that's the only place the problems will occur.  We've had problems with people who compiled OUT session support (enabled by default!)

And either way, we've gone over this-- you already have features in the admin control panel that use GD (if a person supports it):  Settings -> Avatar -> If the avatar is too large... -> Download and resize it (requires GD module).  That's a big red button imo *shrug*

Avatars are a lot less essential than registrations.  If avatars aren't working, they'll ask here.  If registrations aren't working, they'll install another software.

each captcha token/sequence can only be tried once, and then it is replaced with a new token on each subsequent attempt-- successful or not.

So now you're saying my passwords are even LESS secure than captchas?  You're going to have me sleeping with a gun under my log in box!

Even a bad password attempt kills the captcha sequence for that given try and generates another for the next login attempt, thus effectively removing the ability to effectively brute-force a password without a person there entering each attempt's captcha code OR software that does really good guesses on a 1:10,000 probability, 5 digit, random, base-10 number that rotates with every page access-- the only records of which remain hidden in server-side $_SESSION variables and in a human-only readable image.

Using captchas for logins is a complete joke.  Anyone serious enough to really work at it will realize that you can try authentication using the Cookie header, which OBVIOUSLY cannot require a captcha.  And the only solution to that is disallowing "log in forever" which would lose a large percentage of our userbase too.

It's something to think about *shrug*.

I've thought about it, and as much as I do disagree with it, I'm not discounting it.  More importantly, the quality of hosts is - in my opinion - increasing, and I have plans/hopes for it to continue doing so.... don't think there's no future for this idea, but I still don't think it's practical at this point.

I mean, the chances of success anyway in a brute-force attack are slim

Indeed, there are other protections on registration which would definitely slow people down (transparent ones.)

Just think about all the other 14 year old packet kiddies who have nothing better to do than play Quake 3 and eat Funions after infecting their computer labs at school with home-brewed, drone-creating vb code.

They don't have 1000 computers to do a distributed attack on you.... because they'd need 1000 IP addresses.  That's just crazy.

... and don't tell anyone about the gun. 

Well, (assuming you live in America) it's your consitutional right, isn't it?

-[Unknown]

[sauron24]

Security code necessary.

Download and try this.

hxxp:www.tahribat.com/denyolaunch/denyolaunch.asp [nonactive]

hxxp:www.tahribat.com/download/denyolaunch.exe [nonactive] (Engilish)