captcha-payment.txt (5943B)
1 Supporting DDoS blockers with Taler 2 =================================== 3 4 Overview: 5 6 In many IP reputation systems, CAPTCHAS are used to separate humans from 7 bots, allowing humans to access resources while blocking automated 8 attackers. However, especially complex modern Web sites require many 9 resources and thus can trigger a large number of CAPTCHAS, limiting 10 usability. The problem is compounded if users access the Web via 11 Tor or VPNs, as this means mechanisms to track users cannot be used to 12 reduce the number of CAPTCHAS. 13 14 We propose an alternative where we use Taler-style micropayments to 15 automatically pay for access to resources. The micropayments would 16 be done in a provider-specific currency, effectively turning Taler 17 payments into anonymous credentials or tokens. Tokens would be 18 provided by the provider in exchange for the user solving CAPTCHAS, 19 but instead of solving one CAPTCHA per request a user may be issued 20 thousands of tokens for one CAPTCHA, which could then be used across 21 multiple websites without creating anonymity/linkability issues. 22 23 Rationale: 24 25 Reducing the use of CAPTCHA's improves usability for everybody, and 26 by (re)using Taler we limit the need for security audits for custom 27 solutions. Furthermore, it also becomes conceivable to move from 28 CAPTCHAS to actual payments or other mechanisms to hand out tokens 29 (i.e. researchers that legitimately need to perform automated 30 requests may apply for a token grant). 31 32 Challenges: 33 34 To make this work, we need to address three issues: 35 1) Taler needs to add support for an 'auto-pay' flag that would be 36 associated with a currency. If the flag is present, the wallet 37 would not interactively ask the user to confirm the payment, but 38 just automatically pay (if funds are available; otherwise it 39 should redirect to the provider's "bank" where the user would 40 solve a CAPTCHA to obtain tokens). This is relatively trivial 41 and necessary for usability. 42 2) Right now, the Wallet-Web site interaction uses JavaScript. This 43 is not acceptable for some of the CAPTCHA-use case domains, as 44 Tor users may disable JavaScript and injecting Taler-specific 45 JavaScript into generic Web sites is messy. 46 3) The solution needs to work with embedded resources and POST requests, 47 where running a JavaScript interaction for each resource is both 48 too expensive and rather complicated. Instead, a page should indicate 49 that all resources associated with a DOM require payment, and then 50 payment should automatically and efficiently be provided with each 51 request. 52 53 Required changes to Taler: 54 55 We mainly need to make three changes: 56 1) Support for auto-pay (rather trivial), by tagging currencies, and 57 by redirecting to a "bank" page to withdraw tokens if funds are 58 insufficient. 59 2) In the 'withdraw' protocol, the bank should be able to specify the 60 payment system provider and tell the wallet to skip the interactive 61 selection/confirmation dialog (as there is only one provider and 62 thus no choice to be made). This change is also rather trivial. 63 3) Change Wallet to check for HTTP headers requesting payment for the 64 DOM, and then inject an HTTP header in all subsequent requests generated 65 by that page with the payment (i.e. signing the request's URL with 66 the coin/token). This change is non-trivial, and may require 67 browser-specific solutions. 68 69 Technical differences to captcha-plugin-draft.txt: 70 * both solutions use RSA blind signatures for privacy, my reading 71 of the draft is that 256-bits are proposed, while Taler leaves 72 the bit length variable (to the payment service provider). 73 * Taler uses Ed25519 for "tokens", while the draft proposes 74 random nonces as tokens. Taler can thus spend tokens using 75 EdDSA signatures, while the draft uses encryption (of the 76 nonce/Token) with the server's key and a keyed HMAC. I do not 77 attribute either design a significant performance advantage, 78 except with Taler the server could skip checking either signature 79 (to shard load if stressed), while the draft requires server-side 80 decryption to obtain the nonce. 81 Taler's use of an EdDSA signature is also more flexibile for other 82 applications, but in this particular context there is no 83 significant difference to the keyed HMAC with encrypted nonce. 84 * Instead of using the draft's scheme for withdrawing coins by 85 a magic HTML form attribute, Taler's bank API would be used, 86 where the bank (in this case the CAPTCHA-DDoS-protection provider) 87 signals to the wallet that a withdraw operation is being authorized 88 using a JavaScript signal. This is significantly more efficient, 89 as registering a signal handler is O(1) per page, while parsing 90 all DOMs to find a magic HTML form attribute is O(n) (where n is 91 the size of the DOM). 92 93 94 Scalability: 95 96 Given that DDoS-protection has weaker requirements, it would be 97 trivial to use regional double-spending detection instead of global 98 double-spending detection. Also, a custom exchange could use 99 probabilistic data structures to improve efficiency. 100 Alternatively, multiple currencies could be used; for this, the 101 HTTP header requiring auto-pay should simply specify the desired 102 currency, enabling further sharding of the load. 103 104 Benefits of integrated solution with Taler: 105 106 * significant re-use of expertise, code, auditing effort and 107 protocol design 108 * provider-independent free software solution 109 * possibility to trivially "upgrade" to payment or data grants 110 * solution that is not Tor-specific, plugin should work for 111 various browsers 112 * 1 bit information leakage (is plugin present), instead of 2 bits 113 (if there are two separate plugins) 114 * Tor wants to solve CAPTCHA problem, Tor wants to support 115 anonymous payments. This could solve both with 98% 116 shared code.