Live data from Hacker News

mCaptcha – Proof of work based, privacy respecting CAPTCHA system

github.com

61–70 of 100 posts

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

#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., then reject the login and optionally ban the IP address after too many failed attempts.

The 3 sec delay is more than enough to discourage/prevent brute force attacks but not enough to annoy legitimate users.

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

#62

Earlier quoted context omitted.

> I appreciate the effort towards better UX, but there are already "invisible" CAPTCHAs like Botpoison that discriminate better than this. Interesting project, thank you for sharing! From Botpoison's website[0] under FAQ: > Botpoison combines: > - Hashcash , a cryptographic hash-based proof-of-work algorithm. > - IP reputation checks, cross-referencing proprietary and 3rd party data sets. > - IP rate-limits. > - Sess…

> and those behind CG-NAT I'm in two minds about how I feel inconveniencing those behind CG-NAT. I don't want to punish the innocent, but the ISPs aren't going to move towards better solutions (IPv6) without a push from their paying customers, and they'll never get that push with sufficient strength if we work tirelessly to make the problem affect us and not affect those subscribers.

In the real world, on the other hand, customers will simply conclude that one site doesn't work while others do, and that the problem must be with the one site that doesn't work.

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

#68

I looked into doing something like this once and decided it wasn't going to be very effective, for a few different reasons. JS engines (or even WASM) aren'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 challen…

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…

I'd suggest you consider a new name. Captcha stands for Completely Automated Public Turing Test and this implementation has little to do with that.

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

#70

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?
Post reply on HN