[tor-bugs] #10809 [BridgeDB]: reCAPTCHA on bridges.torproject.org are impossible to solve for humans
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Mar 14 15:34:11 UTC 2014
#10809: reCAPTCHA on bridges.torproject.org are impossible to solve for humans
--------------------------+----------------------------
Reporter: lunar | Owner: isis
Type: defect | Status: needs_revision
Priority: major | Milestone:
Component: BridgeDB | Version:
Resolution: | Keywords: bridgdb-0.1.5
Actual Points: | Parent ID:
Points: |
--------------------------+----------------------------
Changes (by isis):
* status: accepted => needs_revision
Comment:
Replying to [comment:15 sysrqb]:
> Replying to [comment:14 isis]:
> > This adds support for using CAPTCHAs from a local directory (created
with [https://github.com/isislovecruft/gimp-captcha my Gimp+Python
CAPTCHA] generation scripts). It also works with my branch for #11127.
>
> It looks sane! (I actually reviewed your fix/11127-recaptcha-
ssl_10809r1_r1, but putting GimpCaptcha review here)
>
> I haven't reviewed GimpCaptchaTests yet, nor run the code, but based on
the review I think there are only two things that we might want to change.
>
> 1) (as i mentioned earlier) it would be nice if we could use both
captcha systems at the same time, so creating a
<blah>CaptchaProtectedResource class that wraps ReCaptcha and Gimp,
selecting one when we receive a request with a preset probability, seems
like the easiest way to do it. The hard part, it seems, will be
determining which system was chosen when we receive the challenge and
solution from the client (but this shouldn't be too difficult).
I am thinking of making this a separate enhancement ticket, since I think
the fine people helping the support desk will have a better quality of
life if we first make human-passable Turing tests.
One thing that has just occurred to me is that, if either reCaptcha or the
gimp-captchas are considered easier, and we have a probablistic wrapper
resource for choosing one or the other, couldn't a user just refresh until
they get the easier one? I mean, the webserver isn't stateful between one
request and the next. Making it stateful would mean rewriting most of it.
> 2) the Gimp code looks good, but I think it would be better if the
challenges were pinned to a time period, e.g. in
GimpCaptcha.createChallenge() prepend the next 5 minute time period to the
encrypted text when you create the hmac for the challenge. Then, in
GimpCaptcha.check(), verify the captcha was sent to the client within the
previous 5 minute period or the current 5 minute period, and continue
processing if one of these is true but not both. (I have no affinity to 5
minute time periods :))
Yeah, I totally agree. There is a TODO comment about it in the
[https://gitweb.torproject.org/user/isis/bridgedb.git/commitdiff/eeb6956ed7f7ddd0f2592c17f4a5d58a580fb878
commit message for eeb6956ed7f7ddd0f2592c17f4a5d58a580fb878].
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10809#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list