I wonder why this approach hasn't been widely adopted?
Allowing abusers to freely abuse would cost even more power than just forcing them to do the work.
disclosure: I'm the author of mCaptcha
I'm the author of mCaptcha, I'd be happy to answer any questions that people might have :)
The maximum advisable delay is ~10s but even then it might not be enough for it to be useful.
Also, here: https://mcaptcha.org/, under the "Defend like Castles" section, I think you meant "expensive", not "experience".
Keep up the good work!
> Instead of an easy mode and advanced one I would use a single mode with a calculator, that way it is more transparent to the user and it would make the process of learning the advance mode and concepts easier.
Makes sense, I'll definitely think about it. The dashboard UX needs polishing and this is certainly one area where it can be improved.
> Also, here: https://mcaptcha.org/, under the "Defend like Castles" section, I think you meant "expensive", not "experience".
Fixed! There are a bunch of other typos on the website too, I can't type even if my life depended on it :D
Of course slowing down DOS attacks is a great goal in itself, and it's very often what captchas have been (ab)used for, but it doesn't seem to me to replace all or most use cases for a captcha. In particular, since it can be completed by an automated system at least as easily as by a human, it doesn't seem like it would limit spambot signups or spambot comment or contact form submissions in any meaningful way.
Or am I misunderstanding, @realaravinth?
I used "captcha" to simplify mCaptcha's application, calling it a captcha is much simpler to say than calling it a PoW-powered rate limiter :D
That said, yes it doesn't do spambot form-abuse detection. Bypassing captchas like hCaptcha and reCAPTCHA with computer vision is difficult but its is stupid easy to do it with services offered by CAPTCHA farms(employ humans to solve captchas; available via API calls), which are sometimes cheaper than what reCAPTCHA charges.
So IMHO, reCAPTCHA and hCaptcha are only making it difficult for visitors to access web services without hurting bots/spammers in any reasonable way.
In addition, using sha256 for this is IMHO a mistake, calling for ASIC abuse.
Glad you asked! This is theoretically possible, but the adversary will have to be highly motivated with considerable resources to choke mCaptcha.
For instance, to generate Proof of Work(PoW), the client will have to generate 50k hashes(can be configured for higher difficulty) whereas the mCaptcha server will only have to generate 1 hash to validate the PoW. So a really powerful adversary can overwhelm mCaptcha, but at that point there's very little any service can do :D
> In addition, using sha256 for this is IMHO a mistake, calling for ASIC abuse.
Good point! Codeberg raised the same issue before they decided to try mCaptcha. There are protections against ASIC abuse: each captcha challenge has a lifetime and also, variable difficulty scaling implemented which increases difficulty when abuse is detected.
That said, the project is in alpha, I'm willing to wait and see if ASIC abuse is prevalent before moving to more resource-intensive hashing algorithms like Scrypt. Any algorithm that we choose will also impact legitimate visitors so it'll have to be done with care. :)
I completely forgot how PoW worked, it's clearer now. You should probably add that this is a probabilistic average, so people will have to be ready for much longer (and faster) resolutions.
With what you said, an adversary can probably just DoS mCaptcha without any computation, if verification is stateless (by sending garbage at line rate); if it is stateful (e.g CSRF token), you'll have to do a cache query, which is probably on the same order of magnitude of a single hash.
A big part of what makes our captcha successful in fighting abuse is that we scale the difficulty of the proof-of-work puzzle based on the user’s previous behavior and other signals (e.g. minus points if their IP address is a known datacenter IP).
The nice thing about a scaling PoW setup is that it’s not all-or-nothing unlike other captcha’s. Most captcha’s can be solved by “most” humans, but that means that there is still some subset of all humans that you are excluding. In our case if we do get it wrong and wrongly think the user is a bot, the user may have to solve a puzzle for a while, but after that they are accepted nonetheless.
There is a blessed source-available version of the server that you can self-host [0]. It is more limited in its protection, but it is probably good enough for hobby projects.
[0]: https://github.com/FriendlyCaptcha/friendly-lite-server
Newer variations (such as argon2) are tunable so you can include memory footprint and cpu-parallelism. There also are time-lock puzzles or verifiable delay functions that negate any parallelism because there's a single answer which can't be arrived at sooner by throwing more cores at the problem.
Beware when choosing a CAPTCHA that serving "most humans" might exclude those with accessibility issues, like the visually impaired.