Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

mCaptcha – Proof of work based, privacy respecting CAPTCHA system

github.com

Post reply on HN
Print view View original

71–80 of 100 posts

Re: mCaptcha – Proof of work based, privacy respecting CAPTCHA system

#71

Post by web007 »

Looks like a decent implementation of HashCash - great! They should implement TOTP-based nonce generation to avoid the need for a database entirely, that would make the system much more lightweight to deploy.

Some people miss the point of this. If you and another person are running away from a cheetah (fastest land animal) then you don't have to outrun the cheetah to survive, just the other person. The same is true for sites getting away from spammers. They will go for sites that are easy to attack before yours, so as long as the effort outweighs the outcome you're safe. It doesn't matter if the solution isn't perfect, it's better than nothing, and if it's not widely adopted it's not worth the effort to bother cracking.

Re: mCaptcha – Proof of work based, privacy respecting CAPTCHA system

#72

Post by zazaulola »

realaravinth wrote: post #3

Hello, I'm the author of mCaptcha. I'll be happy to answer any questions that you might have :)

Check out the latest revision of the gist. I have added some explanations. Do you think this implementation will work more efficiently or less efficiently? What kind of statistics do you collect in the database? Is there anything interesting in these statistics? Is collecting statistics worth the performance slowdown that occurs? How effective is banning a client by IP/IPv6?

Re: mCaptcha – Proof of work based, privacy respecting CAPTCHA system

#73

Post by nneonneo »

This isn’t a CAPTCHA. A CAPTCHA should be something that can tell a human user apart from a non-human user with a high degree of accuracy, such that it should be hard for a bot to pass even a single instance.

As noted elsewhere in the thread, this is a rate-limiting system. It cannot protect low-rate critical resources like registrations, but would be useful in mitigating large-scale spam attacks.

Re: mCaptcha – Proof of work based, privacy respecting CAPTCHA system

#74

Post by jqpabc123 »

orheep wrote: post #70
jqpabc123 wrote: post #61

Much, much simpler solution --- an actual time based rate limiter: 1) Include a hidden, unique token when the login screen is served to client. 2) On the client, enforce a minimum 3 sec delay from time of screen load before the login will be submitted with the hidden token included. 3) On the server, if the hidden token isn't returned or is unknown/not found or if the delay from the time of issue is less than 3 sec.,…

Wouldn’t this exhaust the server resources with storing all the tokens? Which you would need to do significantly longer than 3 secs? Banning the IP may help but then you could just do a simple fail2ban instead?

Wouldn’t this exhaust the server resources with storing all the tokens?

Not really --- only 8 bytes per token and they can be discarded on successful login. Tokens older than X minutes or with more than X attempts can be discarded/rejected too.

How many users are legitimately attempting to log in to your server at the same time?

If you worried about this, encode the current time into the token using a hashing/encryption/checksum method of your choice. This way, everything needed to validate the attempt is submitted along with the credentials.

Re: mCaptcha – Proof of work based, privacy respecting CAPTCHA system

#75

Post by nextaccountic »

mort96 wrote: post #58
realaravinth wrote: post #16

Earlier quoted context omitted.

Thank you for your detailed response, you raise some very interesting and valid points! > JS engines (or even WASM) aren't going to be as fast at this kind of work as native machine code would be 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 implem…

> mCaptcha is basically a rate-limiter. 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. In essence, ngix'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 intuiti…

You can and should use multiple kinds of rate limiters

Re: mCaptcha – Proof of work based, privacy respecting CAPTCHA system

#78

Post by csense »

nneonneo wrote: post #73

This isn’t a CAPTCHA. A CAPTCHA should be something that can tell a human user apart from a non-human user with a high degree of accuracy, such that it should be hard for a bot to pass even a single instance. As noted elsewhere in the thread, this is a rate-limiting system. It cannot protect low-rate critical resources like registrations, but would be useful in mitigating large-scale spam attacks.

According to Wikipedia, CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart. This code shouldn't be called CAPTCHA as it makes no attempt to tell humans from machines. (If anything, SHA256 proof-of-work is a problem that's easy for a computer but hard for a human, the opposite of a Turing test.) I'd call it "Proof-Of-Work Client-side RAte Protection" -- it's a POWCRAP, not a CAPTCHA.

(I invented the acronym just now in this post; it could perhaps use some work.)

Re: mCaptcha – Proof of work based, privacy respecting CAPTCHA system

#80

Post by nneonneo »

jqpabc123 wrote: post #61

Much, much simpler solution --- an actual time based rate limiter: 1) Include a hidden, unique token when the login screen is served to client. 2) On the client, enforce a minimum 3 sec delay from time of screen load before the login will be submitted with the hidden token included. 3) On the server, if the hidden token isn't returned or is unknown/not found or if the delay from the time of issue is less than 3 sec.,…

But this is totally useless - it doesn't consume any resources of the spammer! They can just launch a large number of requests (possibly from their army of bot machines to defeat IP limiting) and have them each wait 3s while doing other nefarious things in parallel.

A PoW has at least the redeeming feature of consuming some resources for those 3s (or so...) making it self-limiting; there's only so many such computations a computer can do in parallel.

Post reply on HN