<story><title>mCaptcha – Proof of work based, privacy respecting CAPTCHA system</title><url>https://github.com/mCaptcha/mCaptcha</url></story><parent_chain><item><author>realaravinth</author><text>Thank you for your detailed response, you raise some very interesting and valid points!&lt;p&gt;&amp;gt; JS engines (or even WASM) aren&amp;#x27;t going to be as fast at this kind of work as native machine code would be&lt;p&gt;You are right. mCaptcha has a WASM and a JS polyfill implementations. Native code will definitely be faster than WASM but in an experiment I ran for fun[0], I discovered that the WASM was roughly 2s slower than native implementation.&lt;p&gt;&amp;gt; It&amp;#x27;s also based on the assumption that proof-of-work is going to increase the cost of doing business&lt;p&gt;mCaptcha is basically a rate-limiter. If an expensive endpoint(say registration: hashing + other validation is expensive) can handle 4k requests&amp;#x2F;seconds and has mCaptcha installed, then the webmaster can force the attacker to slow down to 1 request&amp;#x2F;second, significantly reducing the load on their server. That isn&amp;#x27;t to say that the webmaster will be able to protect themselves against sufficiently motivated attacker who has botnets. :)&lt;p&gt;&amp;gt; There&amp;#x27;s also the risk that any challenge that&amp;#x27;s sufficiently difficult may also make the user&amp;#x27;s browser angry that a script is either going unresponsive or eating tons of CPU, which isn&amp;#x27;t much different from cryptocurrency miner behavior.&lt;p&gt;Also correct. The trick is in finding optimum difficulty which will work for the majority of the devices. A survey to benchmark PoW performance of devices in the wild is WIP[1], which will help webmasters configure their CAPTCHA better.&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;mcaptcha.org&amp;#x2F;blog&amp;#x2F;pow-performance&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;mcaptcha.org&amp;#x2F;blog&amp;#x2F;pow-performance&lt;/a&gt; Benchmarking platforms weren&amp;#x27;t optimised for running benchmarks, kindly take it with a grain of salt. It was a bored Sunday afternoon experiment.&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;mcaptcha&amp;#x2F;survey&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;mcaptcha&amp;#x2F;survey&lt;/a&gt;&lt;p&gt;Full disclosure: I&amp;#x27;m the author of mCaptcha</text></item><item><author>AbacusAvenger</author><text>I looked into doing something like this once and decided it wasn&amp;#x27;t going to be very effective, for a few different reasons.&lt;p&gt;JS engines (or even WASM) aren&amp;#x27;t going to be as fast at this kind of work as native machine code would be. Especially when you consider that libraries like OpenSSL have heavily tuned implementations of the SHA algorithms. Any bot solving a SHA-based challenge would be able to extract the challenge from the page and execute it using native machine code faster than any legitimate user&amp;#x27;s browser could. And if you increase the difficulty of the challenge, it&amp;#x27;s just going to punish real users running the challenge in their browser more than it would the bots.&lt;p&gt;It&amp;#x27;s also based on the assumption that proof-of-work is going to increase the cost of doing business for the bots in some way and discourage their behavior. Many of the bots I was dealing with in my case were either using cloud compute services fraudulently or were running on compromised machines of unknowing people. And they tended not to care about how long it took or how high-effort the challenge was, they were very dedicated at getting past it and continuing their malicious behavior.&lt;p&gt;There&amp;#x27;s also the risk that any challenge that&amp;#x27;s sufficiently difficult may also make the user&amp;#x27;s browser angry that a script is either going unresponsive or eating tons of CPU, which isn&amp;#x27;t much different from cryptocurrency miner behavior.</text></item></parent_chain><comment><author>tusharsoni</author><text>&amp;gt; mCaptcha is basically a rate-limiter&lt;p&gt;This is a much better explanation of what it does than captcha where I expect &amp;quot;proof-of-human&amp;quot;. A PoW based rate-limiter is a really interesting idea! Usually, the challenge with unauthenticated endpoints (ex. signups) is that the server has to do more work (db queries) than the client (make an http request) so it is really easy for the client to bring the server down. With PoW, we&amp;#x27;re essentially flipping that model where the client has to do more work than the server. Good work!</text></comment>
<story><title>mCaptcha – Proof of work based, privacy respecting CAPTCHA system</title><url>https://github.com/mCaptcha/mCaptcha</url></story><parent_chain><item><author>realaravinth</author><text>Thank you for your detailed response, you raise some very interesting and valid points!&lt;p&gt;&amp;gt; JS engines (or even WASM) aren&amp;#x27;t going to be as fast at this kind of work as native machine code would be&lt;p&gt;You are right. mCaptcha has a WASM and a JS polyfill implementations. Native code will definitely be faster than WASM but in an experiment I ran for fun[0], I discovered that the WASM was roughly 2s slower than native implementation.&lt;p&gt;&amp;gt; It&amp;#x27;s also based on the assumption that proof-of-work is going to increase the cost of doing business&lt;p&gt;mCaptcha is basically a rate-limiter. If an expensive endpoint(say registration: hashing + other validation is expensive) can handle 4k requests&amp;#x2F;seconds and has mCaptcha installed, then the webmaster can force the attacker to slow down to 1 request&amp;#x2F;second, significantly reducing the load on their server. That isn&amp;#x27;t to say that the webmaster will be able to protect themselves against sufficiently motivated attacker who has botnets. :)&lt;p&gt;&amp;gt; There&amp;#x27;s also the risk that any challenge that&amp;#x27;s sufficiently difficult may also make the user&amp;#x27;s browser angry that a script is either going unresponsive or eating tons of CPU, which isn&amp;#x27;t much different from cryptocurrency miner behavior.&lt;p&gt;Also correct. The trick is in finding optimum difficulty which will work for the majority of the devices. A survey to benchmark PoW performance of devices in the wild is WIP[1], which will help webmasters configure their CAPTCHA better.&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;mcaptcha.org&amp;#x2F;blog&amp;#x2F;pow-performance&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;mcaptcha.org&amp;#x2F;blog&amp;#x2F;pow-performance&lt;/a&gt; Benchmarking platforms weren&amp;#x27;t optimised for running benchmarks, kindly take it with a grain of salt. It was a bored Sunday afternoon experiment.&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;mcaptcha&amp;#x2F;survey&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;mcaptcha&amp;#x2F;survey&lt;/a&gt;&lt;p&gt;Full disclosure: I&amp;#x27;m the author of mCaptcha</text></item><item><author>AbacusAvenger</author><text>I looked into doing something like this once and decided it wasn&amp;#x27;t going to be very effective, for a few different reasons.&lt;p&gt;JS engines (or even WASM) aren&amp;#x27;t going to be as fast at this kind of work as native machine code would be. Especially when you consider that libraries like OpenSSL have heavily tuned implementations of the SHA algorithms. Any bot solving a SHA-based challenge would be able to extract the challenge from the page and execute it using native machine code faster than any legitimate user&amp;#x27;s browser could. And if you increase the difficulty of the challenge, it&amp;#x27;s just going to punish real users running the challenge in their browser more than it would the bots.&lt;p&gt;It&amp;#x27;s also based on the assumption that proof-of-work is going to increase the cost of doing business for the bots in some way and discourage their behavior. Many of the bots I was dealing with in my case were either using cloud compute services fraudulently or were running on compromised machines of unknowing people. And they tended not to care about how long it took or how high-effort the challenge was, they were very dedicated at getting past it and continuing their malicious behavior.&lt;p&gt;There&amp;#x27;s also the risk that any challenge that&amp;#x27;s sufficiently difficult may also make the user&amp;#x27;s browser angry that a script is either going unresponsive or eating tons of CPU, which isn&amp;#x27;t much different from cryptocurrency miner behavior.</text></item></parent_chain><comment><author>mort96</author><text>&amp;gt; mCaptcha is basically a rate-limiter.&lt;p&gt;Hmm, is it a better rate limiter than others? I know that nginx, for example, makes it pretty easy to rate limit based on IP address with the `limit_req` and `limit_req_zone` directives.&lt;p&gt;In essence, ngix&amp;#x27;s rate limiter also works by making each request consume a resource, but it makes the resource consumed an IP address (or range) rather than compute resources. It seems intuitive that a malicious actor would have an easier time scaling compute than IP addresses, while a legitimate user will _always_ have an IP address but might be on a machine with 1&amp;#x2F;100000th the compute resources of the malicious actor.</text></comment>