I was hoping to get some tips I could use, but my use of a CAPTCHA isn’t on the web, it’s to allow legacy Telnet access to my Multics installation. It all started with a MASSIVE amount of automatic cracking attempts, which I linked to the Mirai botnet, but simply have never slowed down!
My solution was to present untrusted connections via legacy methods like telnet a text-based CAPTCHA - I am using only low ASCII characters for numbers and lowercase letters A through F, because at that stage of the connection, I can’t be sure exactly what terminal type the user is connecting with:
Please input the following text to enable access from your host.
You have 4 chances, 15 seconds each, or else you will be banned.
_ _
| |__ __| | __ _ ___
| '_ \ / _` | / _` | / __|
| |_) || (_| || (_| || (__
|_.__/ \__,_| \__,_| \___|
>
I tried various methods for turning the tables and lessening the burden of proof on the human to prove they are human, like examining keystroke timing, but everything I tried seemed to increase the false positive rate unacceptably!
My biggest complaint with this CAPTCHA system is, by it’s nature, it makes my resources inaccessible to computers - which means it also makes things inaccessible to those who depend on computer-based accessibility tools, such as those used by the blind.
For my Multics use-case, it’s OK, because there channels like Mosh or SSH connections that are exempted from the CAPTCHA and won’t affect blind or disabled users. As more and more of the web moves to programmed JavaScript-based pages, I worry that it’s becoming less accessible, or that disabled and blind users will be forced to experience second-rate presentation and content.
Could this visual ASCII art captcha be replaced by a plain string prompt like “please type the following word: peacock” that would work fine from a screen reader? No bot author is actively trying to break it, if I understand you correctly? The hordes of logins are just from a bot that wants to log into crappy IoT kit with exposed telnet and default passwords?
That would probably work pretty well I imagine: bots which just target open telnet ports would fail, but computers could still easily be programmed to automatically log in (if the challenge is always on the form “Please type the following word: (.*)”).
Also, in my case - since I offer connections via SSH, Mosh, and VNC I’m less concerned, but, also, if you solve the CAPTCHA just once, that particular IP is exempted from having to solve it ever again.
I love solutions like this. Spam classification is interesting on its own, but laying traps for spambots really takes it to the next level in such a fun way. Of course this can be impractical for small sites that don’t have a lot of resources to design and deploy these kinds of mitigations. And naturally some people don’t find this fun at all, or the most productive use of their time. But wow I enjoy it way more than what’s probably normal.
This works if you are a small site defending against automated bots scanning the web but as soon as you have a spammer targeting your website in particular an invisible form wont stop them. Many big services have found the solution and it’s not one many of us here will like, require a phone number for all signups (And block services to generate phone numbers) and it’s massively harder to spam. Getting phone numbers is a huge pain in the ass and they often cost a decent amount per number which blocks almost all spammers.
I was hoping to get some tips I could use, but my use of a CAPTCHA isn’t on the web, it’s to allow legacy Telnet access to my Multics installation. It all started with a MASSIVE amount of automatic cracking attempts, which I linked to the Mirai botnet, but simply have never slowed down!
This is issue is affecting many other legacy system providers as well (see their 07-Jun-17, 01-Dec-17, and 04-Dec-17 updates).
Example of what I’m seeing over a period of about two or three months:
My solution was to present untrusted connections via legacy methods like telnet a text-based CAPTCHA - I am using only low ASCII characters for numbers and lowercase letters A through F, because at that stage of the connection, I can’t be sure exactly what terminal type the user is connecting with:
I tried various methods for turning the tables and lessening the burden of proof on the human to prove they are human, like examining keystroke timing, but everything I tried seemed to increase the false positive rate unacceptably!
My biggest complaint with this CAPTCHA system is, by it’s nature, it makes my resources inaccessible to computers - which means it also makes things inaccessible to those who depend on computer-based accessibility tools, such as those used by the blind.
For my Multics use-case, it’s OK, because there channels like Mosh or SSH connections that are exempted from the CAPTCHA and won’t affect blind or disabled users. As more and more of the web moves to programmed JavaScript-based pages, I worry that it’s becoming less accessible, or that disabled and blind users will be forced to experience second-rate presentation and content.
Could this visual ASCII art captcha be replaced by a plain string prompt like “please type the following word: peacock” that would work fine from a screen reader? No bot author is actively trying to break it, if I understand you correctly? The hordes of logins are just from a bot that wants to log into crappy IoT kit with exposed telnet and default passwords?
That would probably work pretty well I imagine: bots which just target open telnet ports would fail, but computers could still easily be programmed to automatically log in (if the challenge is always on the form “Please type the following word: (.*)”).
It guess it absolutely could - yes.
My concern and reason for not doing so originally was a concern that such a trivially solvable solution would quickly be trivially solved.
Of course, my concern might be overblown.
Also, in my case - since I offer connections via SSH, Mosh, and VNC I’m less concerned, but, also, if you solve the CAPTCHA just once, that particular IP is exempted from having to solve it ever again.
I love solutions like this. Spam classification is interesting on its own, but laying traps for spambots really takes it to the next level in such a fun way. Of course this can be impractical for small sites that don’t have a lot of resources to design and deploy these kinds of mitigations. And naturally some people don’t find this fun at all, or the most productive use of their time. But wow I enjoy it way more than what’s probably normal.
This works if you are a small site defending against automated bots scanning the web but as soon as you have a spammer targeting your website in particular an invisible form wont stop them. Many big services have found the solution and it’s not one many of us here will like, require a phone number for all signups (And block services to generate phone numbers) and it’s massively harder to spam. Getting phone numbers is a huge pain in the ass and they often cost a decent amount per number which blocks almost all spammers.
You can also consider rate limits. You probably should. Also, forms must have CSRF tokens.