[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Captcha implementation: which way to choose?

From: Dmitry Borodaenko
Subject: Re: Captcha implementation: which way to choose?
Date: Mon, 2 Aug 2010 17:56:18 +0300

I'm including imc-tech ML in this discussion.

Background for imc-tech: Samizdat is a free CMS written in Ruby and used
by several IMCs, including Belarus and Ukraine. It currently lacks
efficient protection from spam bots, to stop being swamped by spam these
sites had to turn the anonymous posting off.

As one of the options to bring back anonymous posting (having to
register, even if all that's needed is a throw-away email account, has
turned many users away, not to mention running contrary to Indymedia
principles), we're considering implementing a Captcha protection.

On Sun, Aug 1, 2010 at 02:41, Hleb Rubanau <address@hidden> wrote:
> "CAPTCHA" class from rubyforge:
>    + is native ruby library, independent from any 3rd party services
>    - last release was in 2004 -- it does not seem to be actively supported, 
> and I have no idea whether algorithms from 2004 are still remaining strong 
> and secure in 2010.
>    - I did not estimate, but I have intuitive feeling that generation of 
> graphic captchas can seriously affect server's performance under high load

In addition to the obvious risk of most likely being useless against
many spam bots (after all, there is an ongoing arms race between Captcha
methods and spammers), being not actively maintained is a security risk
of its own. I've seen a major site penetrated due to vulnerability in a
Captcha implementation, what if a similar vulnerability is found in the
Ruby Captcha? Will any security expert (white hat hacker) even notice?
Will there be anyone able to fix it quickly?

One more drawback of the Ruby Captcha module is that it doesn't do
audio-captcha, which would make it impossible to use for vision-impaired

> Google's "Recaptcha":
>    + does not affect server performance, as all processing is done on 
> third-party servers
>    + is an active product, supported by google developers
>    + has a social benefit: service is a part of project on books digitizing
>    - is a corporate service
>    - has a security hole: google tags are injected in page shown to user
>    - requires site owner to obtain API key from google, and bind it to domain

I strongly suspect Indymedia project wouldn't accept this. I remember
Google Analytics was panned on imc-tech for similar reasons. Trusting
privacy of site's users to a corporate entity runs contrary to
everything Indymedia stands for.

> Self-made textual captcha implementation:
>    + do not require 3rd-party service
>    + should not affect site load significantly
>    - textual captchas are considered relatively weak in comparison w/ 
> graphical ones

Implementing Captcha is a very common problem, let's make sure there's
definitely no other option before starting yet another implementation.

> I would very appreciate any opinions on topic, b/c it's not obvious for me 
> which approach best suites to the samizdat architecture (except of 
> google-bounded: I believe it's unacceptable).
> Also I am not sure that all possible variants are described above.

A fourth option would be to find a Captcha implementation that is
agnostic of site's implementation language. It doesn't really have to be
Ruby as long as it does the job.

Dmitry Borodaenko

reply via email to

[Prev in Thread] Current Thread [Next in Thread]