IPB Should Use reCaptcha For Login Purposes

[Gabriel Petrelli]

I don't human verification questions being cracked by spambots any time soon. While it is true it won't stop human spammers, it is highly effective against 98% - 99% of all automated registrations and posting activities as a result of automated scripts. It is even more so effective if you only use questions that actual/genuine visitors and members who visit your site would know.

Questions like: "What kind of forum is this?", "What is the site's name?", "What software does this forum use for it's board software?", Who is the Root admin of the site?".

You could also ask them what the name is of other sites that reside on your domain are, ask them a question that appears in one of the sticky threads on your forum.

Just be creative and not ask something generic that most other people will use, that won't easily be added to the spammers databases. I find verification questions a bit easier than the sometimes indecipherable text of some captcha's/recaptcha's.

[Connor T]

Thats genius. A session for the register page, and login page.

Its re-made every visit, something a script doesn't do because it doesn't physically download and see the page.

[Rheddy]

dragyn. that is an excellent idea, but it should be for any kind of posting that the recaptcha should be there for, mostly just forum posting and for sending PM's.

[Tim Dorr]

Do the recaptcha at the post/pm screen, not login screen.

Better idea: Do it on login, post, pm, whatever screens. Anything that POSTs. But, only do it after 1 or 2 failed attempts at using those systems or if they are deemed to be "flooding" that particular process.

Look at Google's login process. If you get the password incorrect on your first try, you have to solve a CAPTCHA on your 2nd attempt. Putting a CAPTCHA in only after a failed attempt at something would prevent brute forcing. Putting one after hitting a flood limit will act as a governor on the speed at which someone uses that function. You can even do it with soft/hard limits to have absolute stopping points. So, a lighter soft limit would kick in the CAPTCHA and the hard limit would prevent any attempt until they slow down to at least the soft rate.

It's the best of both worlds because it doesn't interrupt legitimate users.

[bfarber]

Better idea: Do it on login, post, pm, whatever screens. Anything that POSTs. [i]But[/i], only do it after 1 or 2 failed attempts at using those systems or if they are deemed to be "flooding" that particular process.

Look at Google's login process. If you get the password incorrect on your first try, you have to solve a CAPTCHA on your 2nd attempt. Putting a CAPTCHA in only after a failed attempt at something would prevent brute forcing. Putting one after hitting a flood limit will act as a governor on the speed at which someone uses that function. You can even do it with soft/hard limits to have absolute stopping points. So, a lighter soft limit would kick in the CAPTCHA and the hard limit would prevent any attempt until they slow down to at least the soft rate.

It's the best of both worlds because it doesn't interrupt legitimate users.

That method is good at stopping brute forcing - it's not good at stopping bots, who will be "successful" in their post on the first try. Programs are a bit more efficient than humans at that sort of thing, unfortunately. ;)

[Connor T]

but then won't they only get 1 spam PM out?

Seems like a method that might work.