CAPTCHA support for rate limiting and abuse prevention as alternative option to IP based limiting

[daluu]

Not suggesting to replace the IP based limiting with CAPTCHA, but that the server offer that as an alternative option to use. Or maybe even an option to combine both.

Using CAPTCHA, there would be some session state management on server side, and dependency of CAPTCHA image generator and code verifier instead of expected use with a reverse proxy.

It might be interesting to have with the public service, although I actually prefer the public service as it is now since there is not many (almost if any) free SMS messaging services that don't have much restrictions (require signup, trial only, severe limiting). This public service is the best (free) SMS API so far that I've encountered.

FYI, there is another free SMS service that I have used that uses CAPTCHA as their method of abuse prevention and rate limiting, and it has an API. Sadly, due to the CAPTCHA though, unlike this API, it isn't of much use outside of GUI based clients. And sadly they don't open up the source code to the API/service, but at least the service is free.

http://watacrackaz.com/autosms/api.php

[typpo]

+1 to public service. This has been on my todo list for a while and a pull request would be awesome ;). I expect it would need a captcha.

[daluu]

I hope that doesn't mean the public service will be captcha only eventually. Captcha is good for GUI clients/consumers, but bad if one wants to use the API/service with automation, other APIs, or CLI tools that are GUI less.

[typpo]

#49

[daluu]

We can use this for CAPTCHA perhaps: https://www.google.com/recaptcha

[daluu]

This has been marked closed, but I think it shouldn't. My original suggestion is not issue 49 that has superseded this. Rather it is about making CAPTCHA support part of the REST API itself much as how AutoSMS previously referred to does it, although they're closed source so I have no idea how they actually implement it.

But as an example, with cookie session support, one needs to request for CAPTCHA code with call like http://www.watacrackaz.com/autosms/autosms.php?getcode=1 which returns the CAPTCHA code as image (associated to the session) then in subsequent API call to send text message (using same session cookie), supply the CAPTCHA code value as text (this means the "user" must visually/manually view the CAPTCHA and type into form, etc. and that form's logic passes the entered code with/to the API call to Textbelt). On receiving the request to send message, Textbelt would check if the code matches the given session and if match sends the message, else just returns failure. A new CAPTCHA code can always be requested for the same session (e.g. user just wanted to ask for a different/new CAPTCHA, or user made a typo or interpreted code incorrectly and thus forced to enter new CAPTCHA code).

With such CAPTCHA, I was thinking this would be an alternative rate limiting method. Meaning if CAPTCHA supplied, then do not trigger the IP address based rate limiting, otherwise following current logic. So the "client" that consumes the Textbelt API has a choice of using the CAPTCHA option or the IP rate limiting option.

Note that with this method, no session cookie support on client means CAPTCHA method not supported (or it will fail due to session not matching code).