[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