Paul Butler.org

Update: Due to lack of time and interest (on my part), I am no longer maintaining JSSpamBlock or ImageScaler.

I just noticed a trackback from Brandon Cheketts about a PHP script he has released that lets you incorperate functionality similar to JSSpamBlock in any website, called bcSpamBlock. He also released a WordPress plugin based on JSSpamBlock that uses the script.

Although both plugins take advantage of the same limitation of spam bots - that they ignore JavaScript, the way they verify the codes is different. While JSSpamBlock uses a database, bcSpamBlock uses one-way encryption to verify the codes. Although this is a clever way to do it, I chose not to do it in JSSpamBlock for a reason: Storing the code in a database ensures that, even if a spammer were to write a bot targeting sites with JSSpamBlock, each comment posted would require the bot to parse another page from the server. Each code sent to the browser can only be used once. The problem with not using a database is that you have no way to verify that the codes sent from the browser are being used for the first time, and not the 10th.

Georg Kaindl made similar comments about the database being unnecessary, and I wrote a more lengthy response explaining why it was. He then came up with a clever solution - including the post’s ID in the hash. It still isn’t quite as secure as JSSpamBlock (I hate to use the word “secure” to describe what I admit is “security-by-inconvenience”, but I can’t think of another word that fits), but for all practical purposes it should be just as good. The only difference is that spammers could post multiple comments to any given post while only parsing the page once, while JSSpamBlock would require the page to be parsed once for each comment. The other advantage is that I do not have to rely on the JSSpamBlock user to come up with a unique salt in order for the protection to be secure. bcSpamBlock gets around this in a clever way, by using unchanging environment variables to generate the salt.

Another way to look at it is that generating a random code for each page view does not actually increase security (over using the same code for each page view) unless you use a database. So for a plugin that doesn’t use a database, this only gives the illusion of security. You might as well use the code “4422″ for everything, and it would be just as secure. This might sound bad, but any bot that is currently blocked by JSSpamBlock would be blocked by this as well. The only reason JSSpamBlock does more is to make it harder to write a bot that specifically targets JSSpamBlock. It may sound egotistical to suggest that a spammer would ever bother to write a bot specifically targeting the plugin, but for the extra cost (milliseconds of CPU time), I think it is worth making the plugin future-proof.