Spam Bots and CAPTCHAs

Many people, including me, believe that security by obscurity gives a false sense of security. Any security tool must be available in source code, even to bad guys. But Advanced Textual Confirmation (ATC) is encoded. Why?

It’s all about the business. If I deliver the tool as is, some “alternatively smart” programmer can copy/paste the code in a few minutes and start selling the clone. This is my worry: “alternatively smart” programmers.

To satisfy those who are against security by obscurity, I’m diclosing the ATC internals is this post. Warning: to understand the text in full, you have to be a web programmer.

The second step of the script is to decrypt its code. I said second? Yes! The first step is to check what is the request method. If it isn’t POST, it means the user doesn’t modify the data on the server, and therefore there is nothing to protect. Small, but useful optimization.

From the high level point of view, the ATC functionality is:

* Get the value of the cookie bbas_pass_code
* Calculate the expected value
* If the both values are the same, accept the request,
*    otherwise, suspend the request and display the confirmation form.

The alternative work flow is processing of an answer:

* If the user answered correctly, give him the cookie and resume the request,
*    otherwise, display the form again, probably with a new question.

Everything seems quite logical, the only question is how “the expected value” is calculated. This pass code is a cryptographic cash of the client/server data:

* SERVER_NAME, SERVER_ADMIN,
* HTTP_USER_AGENT
* REMOTE_ADDR, HTTP_VIA, HTTP_X_FORWARDED_FOR (Actually, only the first three digits are used. It’s an usability trick for users behind the balancing proxies.)
* The questions and answers.

Thanks to cryptography, the only way to get a correct pass code is to really answer a question.

It worth mentioning that all the ATC identifiers in the confirmation form are also cryptographic dynamic. A spammer can’t use a simple database “fill this form elements with such values” like for other protectors, he has to really load the form and parse it.

The rest isn’t so important. There are some neat tricks and workarounds which make the script a piece of art, but that’s not about the security.

Do you see how the spammers can bypass the protection? I see two methods:

* database of answers, and
* pass code theft.

The first method is the most obvious, many people think it compromises the protection, but I (and practice) disagree. The arguments are in this blog post: “Are your sneakers tied?”

The second method is a bit tricky, bit somehow more effective. A spammer answers a question in browser, gets a pass code and gives the identification information to a spam bot. After that, ATC considers the spam bot to be a legitimate user. Fortunately, this attack doesn’t scale:

* Spammers use botnets and proxies to send spam, but the pass code is bound to the original spammer’s IP.
* Spamming from the same IP is a flood attack. Any good modern forum or blog has protection against it. In the worst case, just ban the IP.

As you see, even if the spammers know how are you protected, they can’t convert the knowledge to actions.