IMHO CPATCHA is a lazy way to protect your service as you shift the burden to your users.
Maybe if you are big and essential for some users, you can afford that. But if not, be aware that users will turn their back on you if you add obstacles between them and your service.
Edit: meant to say “be aware that some users will turn their back to you”
I run a small forum, and it was getting flooded with fake and spam accounts, the moderators were struggling to keep up and the users were finding it annoying. So I put a captcha on the registration page. The problem went to zero, new users still showed up, and more people were happier than before.
But if not be aware that users will turn their back on you if you add obstacles between them and your service.
You have to balance that against how many users you'd lose if the site was down/vandalized/compromised by an attacker if the captcha protection wasn't there to keep it out.
It's often worthwhile moving the captcha away from the initial login or signup form and only putting it on the second or third attempt to login, or on features that put significant load on the server.
> It's often worthwhile moving the captcha away from the initial login or signup form and only putting it on the second or third attempt to login
Though if your service is a lucrative target for {uname,pass} combolist spam, you'll see that each attempt comes from its own IP address and only makes that one request. It's pretty sobering.
Like most kinds of gated security, many solutions are borne out of inspecting the payload instead of who's sending it.
Captchas prevent bots from submitting spam, but they don't prevent humans from submitting spam. In 99% of cases, your problem is the spam, not who is submitting it. The non-lazy solution is to look at the content itself and directly determine whether it's spam, instead of relying on a related heuristic (e.g. who submitted it) to make an informed guess.
This isn't an alternative solution, just one you could do alongside making it difficult for drive-by bot spam.
For example, let's look at an actual service for identifying spam payloads: Akismet. It still lets a lot of spam through, especially in non-English languages.
This is a solution that, if done "perfectly", should be able to catch 100% of spam submissions. This is in contrast to things like captchas (because they "test" something other than the end-goal [no spam] to guess at whether something is spam or not, while ignoring spam from humans [or humans filling out captchas on behalf of bots], and cause problems for both humans and benign bots).
Obviously, it's an extremely hard problem that is hard to do 100% correctly. But it's a viable non-lazy solution (that still needs a lot more work than the current state-of-the-art implementations) compared to the lazy solution of just putting captchas on the page.
The ideal solution would get rid of spam without inconveniencing users who aren't submitting spam, I'd think, which means captchas aren't it.
Honest question - if you set it up so the user gets an email with a link they have to click before their message is actually sent to your queue, would that help?
I'm thinking it would probably reduce the number of users who successfully contacted you legitimately, but CAPTCHAs also do that. Do spammers actually have the email accounts they claim to and respond to confirmation emails?
It would definitely help, I highly doubt spammers would use that sort of mechanism.
The solution gets around potential vendor lock-in and privacy issues with a service like Google's, but it still fundamentally shifts the problem from the service to the user (the original commentor's gripe).
But this is exactly the point I am trying to make. That's the service provider's problem and not the user's. CAPTCHA shifts the problem to the user.
CAPTCHA is a 00's idea, when we had the multiple page registrations(with errors showing only after you submit the page), the insane password requirements, etc.. It doesn't belong to modern stack in my opinion.
"What is the non-lazy solution?" That's how disruption is born.
Almost. It gives a botness score to the server, and it's up to the website to decide what to do with that score. They can pick a threshold to approve, reject, or apply stricter verification to.
Yes it's trade off as usual.
The main benefit I see is on networks where you've a mix of good and bad traffic and you would still like to offer the service to the few good users.
I see this a lot on networks hosting a lot of free VPN providers. The other option we choose before was outright blocking. That is even more harmful for the few good users.
Maybe if you are big and essential for some users, you can afford that. But if not, be aware that users will turn their back on you if you add obstacles between them and your service.
Edit: meant to say “be aware that some users will turn their back to you”