CAPTCHAs are actually hard Many assumptions: ● Culture ● Language ● Vision/hearing ● Mobility ● Social class Define “house” or “storefront” for everyone?
Why do we serve CAPTCHAs? Mostly, IP reputation of the Tor exits Prior attack sightings lead to poor reputation Thus, traffic from exits gets a CAPTCHA
What we’ve tried ● Intentionally blacklisted the office IP reputation ● reCAPTCHA v2 (which backfired - sorry!) ● Customer sites can whitelist Tor network as a “country” ● Altered the internal treatment of Tor traffic ● … some clever crypto thing?
Requirements We need to meet security requirements of both Cloudflare and Tor Browser ● CAPTCHA solutions allow a finite number of subsequent redemptions ● Unlinkable tokens ● Don’t require persistent client state / disk storage ● Resists farming ● Resists double-spend with minimal server state ● Relatively efficient server computations ● Deployable in a browser extension, in Javascript, in an auditable manner
Blind signatures for rate-limiting Tor Browser plugin + an edge service User solves a CAPTCHA and submits many blinded tokens for signing Later, unblinds and submits a token instead of solving CAPTCHA Users solve only one challenge per N websites visited Tokens are unlinkable, work cross-domain over multiple circuits unlike cookies Maintains Tor Browser’s strong first-party isolation
Future Directions But really- RSA? ● Suggestions welcome! But it must be practical to deploy in a browser Anonymous credentials: ● BLAC/BLACR (pairings? in a browser?) ● “Algebraic MACs and Keyed-Verification Anonymous Credentials” Standardization: ● This is generalizable to VPNs and carrier-grade NAT
Open Questions Deanonymization: does this create new vectors? Stockpiling: how do we limit token farming? Exhaustion: how to stop a malicious site from draining tokens?
gtank
skipperchong
bermonpainter
lynnandtonic
robhawkes
speakerdeck
colly
wjessup
swwweet
mongodb
jasonvnalue
andyhume
davidbonilla