Hi Mark,
Good points you've brought up in regards to my question earlier.
However, I don't fully agree that a secret component as you've described
it is entirely necessary. While noone with current technology should
ever expect a panacea in regards to solving this problem, the fact
remains that randomisation with quality entropy can serve as the
effective 'secret' as you've described, which is why I mentioned it
twice; once in regards to the answers array, and once again in regards
to the answer-selection identifier placement. Given 8-12 or perhaps even
up to 64 'mini' images with a quality randomiser and a proper
application of the randomness, I would suggest it's considerably more
solid than near total negation as you suggested. For starters, let's
remember that somewhere between panacea and utter pessimism is where the
answer always lies, so we've got that for starters. Second, the
randomness factored by the answer-identification markers factored by the
number of answer images, it COULD be done with a higher degree of
effectiveness than current deployments. Since it is not a magic bullet,
yes, given enough iterations eventually a machine will succeed in
guessing the answer. However, if the answers are cognitive derivatives
requiring input of multi-character words, patterns etc., displayed as a
part of the image no less (not a flat unicode below the image!), then
there's no solid way for a machine to even know WHAT to input. Properly
implemented and randomised, and with enough questions and answers
comprising the static vars portion of the software that you suggest
entirely negate it's value; the percentage of accurate machine-guesses
versus the reliable and simple (a million vars, choose one(random)) is
going to be no better than "one in a million" (as you can see i'm no
statistician ;).
Anyway, I'm not trying to be disagreeable and perhaps we'll have to
agree to disagree, but I feel that the way I explained it which i THINK
is accurate to the way it is conceptualized in my head, makes it far
more viable than you had suggested by 'useless via source exposure', but
of course as I stated it certainly would not be the final say either. I
do think it'd be far preferrable to current implementations if it were
done correctly; and that is to spend the most time on accurate standards
and main iterations, but keeping the core process stupidly simple (to
avoid bugs and injecting predictability). Carnegie Mellon seems to think
it has some merit which I was glad to see the link to; in fact, the
drop-down word selector on their implementation had somewhere around 32
variables/words or thereabout. Couple that with the statefulness
required during signup over http in most if not all cases, that kills
the possibility of bad source addresses and therefore process-count
source address banning can be implemented if someone is engaged in a
guessing game over N amount of time.
Sorry so long winded, just wanted to address the differences I felt in
viability with my presentation (and that of where carnegie mellon is
taking it as well). Random is the secret of which you speak. The rest is
safety in numbers prior to source-quashing........
Best Regards,
Jayson
On Thu, 2005-08-25 at 11:32 -0600, Mark Burnett wrote:
The problem with coming up with effective CAPTCHA's is that the dataset
should not rely on obscurity or secrecy to work. Anyone can come up with hard
questions that can consistently trip up a computer, but how effective would
those questions be if the adversary had access to your question/answer
database? Many ideas I hear for CAPTCHA's rely solely upon the secrecy of the
data set. And that is security that relies upon obscurity.
Try coming up with a CAPTCHA where the code is public, the dataset is public,
and the only secret is the randomness generated for each individual test, and
you will find that it is quite difficult. The problem, in part, is that we
want a machine to generate a test that another machine with the same data
cannot solve, but that a human can. We can bypass that by having humans come
up with the questions, but that means they also need to store the answers for
verification, again bringing us back to the problem that we are relying upon
the secrecy of the data.
Another mistake that people often make with CAPTCHA's are questions with
multiple choice answers. If you asked a question like "Which of these
strawberries is most rotten?" you would have to provide enough pictures to
reduce the significance of a luck guess. Even if you had 10 possible answers
to select from, that might not be effective in stopping a spammer from
setting up massive free e-mail accounts. It might statistically take them 10
times as long but they can still do it. However, if you provide too many
answers, the chances of several good answers increases, making it less
effective. How many times have you taken a multiple choice test and there are
two answers that, in your opinion, would work? Especially in the case of a
subjective question such as which strawberry is most rotten.
It is definitely a good challenge and it will be cool seeing someone someday
solve this problem.
Mark Burnett
On Thu, 25 Aug 2005 08:40:40 -0700, Jayson Anderson wrote:
That was an interesting article, I definetely got caught up clicking
thru for awhile.. One has to wonder, why hasn't a more effective system
been placed into production let alone conceptualized and largely
accepted as a solid approach for the future ? More specifically, the
claim that CAPTCHA as it stands now is not a Turing machine. I'm not
sure if that's entirely true as symbols pre-date their interpretation by
machine.=20
Regardless, like one gentleman mentioned in an article, a much more
clear method to differentiate man vs. machine would be to ask abstract
questions. Barring the cultural, linguistic and socioeconomic
implications, why not ask things like "which one is a pachyderm?". Or
"which texture most resembles stipple?". Or "Which of these strawberries
is most rotten?". Or "Which person is taller?" with same-sized figures,
but one the same sized as the car she stands next to, the other only
half. etc. etc. Ya know ? Sure it would take a significant multi-faceted
approach utilizing an amazingly heterogeneous set of contributors, but
that's where open source comes in. Pool a huge bank of acceptable
abstracts based on image size, obscurity and all the other standards
(which do NOT need to be complex at all), then refine that, seed the
array and answer presentations with some decent entropy, use yet more
entropy to randomize the units by which answers are delineated,
"a,b,c,d", "circle[~],eye{=3D],carrot[%],money[E]" each different each
time, and all the hundreds of other variables i've not thought of. It
seems like it is workable to me. Keep the project always living so that
submissions and refined objects are always being added to an update-able
system..... SOMETHING is going to have to be done that is superior to
"crazytext", as ultimately it will be rendered nothing worse than a
speedbump. I think CAPTCHA still qualifies as Turing, just not an
effective one in it's environment. Seems that machine-proofing should
use anything BUT that which is found in almost every machine that would
be used to circumvent it :)=20
Sorry for the chatter but I've ALWAYS felt that crazytext(tm) was an
amazingly poor way to differentiate machine from man, and these articles
just prove what I and so many others I'm sure had always felt.....
Jayson
-
On Wed, 2005-08-24 at 14:29 -0400, robert@webappsec.org wrote:
This was linked off of slashdot
(http://it.slashdot.org/article.pl?sid=05/08/24/1629213&tid=172&tid=95)
and explains some of the ways people are breaking CAPTCHA
(http://en.wikipedia.org/wiki/Captcha) based systems.
http://sam.zoy.org/pwntcha/
- Robert
robert_at_webappsec.org
http://www.cgisecurity.com
