Page 3 - Captchas

I kind of liked Kicken's method for fighting spam. I'll have to add Kravvitz's...Kravvitz'...I don't know what the possessive of your username should be (really). Erm, anyway, booked marked those links

Well the truly enjoyable and recreational way to fight spam is to find a spammer, beat the living crap out them and smash every computer they own. Barring the opportunity to do that...

One thing to note about all this is, that if you come up against someone of equal or greater programming experience and knowledge then you have, you have your work cut out for you. Unless that person is doing it for fun, or has a personal grudge against you or your hoster however, that wouldn't be very common unless there was something about your site or your visitors that was especially attractive to them.

Those people make much more money selling "kits" to less technically oriented spammers and phishers. Depending on how cleverly put together those "kits" are, they may have some ability to adapt to the situation, but not as much as a human would. The people using them, might only have a rudimentary knowledge of HTML. Most of the measures mentioned, for an average site, would work a majority of the time for that reason.

While it runs blindly in the face of accessibility, I prefer getting the user to interpret an image. For example:

Then ask the user to identify something about the picture, IGNORING the text within the image, for example: "What shape is the roof?". Since most bots are looking to implement OCR, it will read the text and answer "Blue." Brilliant, bot.

Another way to do it is to make your form two pages. Give the user a key on the first page that they must write down or remember. For example:

1. Server generates key, saves it, and presents it to the user on form page 1.
2. User remembers the key, fills out form page 1, and clicks next/continue.
3. The server serves form page 2, but the page does not contain the key.
4. The user fills out form page 2, enters the key, and presses submit.
5. The server checks the key against its saved keys. If the key is good, submit. If not, error out back to the user.

Also easily hackable if the spammer investigates your page before sending in his/her bot, but not for simple spiders.

I think the key here is that as long as you don't have a big target painted on your back a standard captcha will probably work, and if it doesn't you probably just have to do something a little different so that whatever canned package your attacker is using get's confused.

And the only sites that really have the big targets on their backs are sites with large direct-spam potential: e-mail or blog providers of a sufficient page rank, for example.

So. I'm trying to figure out how to explain that any kind of spam prevention at the form/request level is useless when the email address the entry goes to is in plain text on the html page...

In the case of mail header injection, an attacker can use a contact form as a spam relay to send messages to hundreds of recipients, untraceable to them. They can add recipients, alternate subjects and messages and attachments, depending on the degree of vulnerability.

When you publish your email address, then they can certainly send you spam, but that can also be filtered by an effective spam filter. They won't however be able to utilize your server, and the network it's on, to send unlimited spam to others.

So there is some difference.

Nar it's more than that. Say you are using a widely used system like Joomla, Media Wiki or some popular Forum app that uses a Captcha system. If the robot manufacturer works out the system for one site they essentially work it out for all the sites using that system. Sure their initial attack may be against one site they had a grudge against but the potential for future attacks on other sites is huge.

If any of these protective measures were truly effective we wouldn't be receiving spam, would we?

Back to the drawing board.

Oh, incidentally, you super-sharp mofos might like to note how "receive" is spelled. Small point, but if you don't pick up on it I don't trust your most mundane recommendations.

Its much worse that you write. They are not marginally effective. They are at best security theater. They also make it hard for folks with disabilities. So we have reliance on a system that does not work, and makes it hard for a portion of the population to use the system.

They need to back up and fix the basic principals, rather than putting bandages like captchas on a broken system.

I would argue that fixing the basic principals, at least in my terms of "fix", is a major felony. Perhaps the principle of "self defense" would hold up, perhaps not.

My fix would be legal, but nearly as hard.

The concept of SMTP is built on trusted networks. It was OK back in 1975 or so, its not justified today.

So we would have to change the fundamental RFCs for email, and while we were at it, we should do something like move to IPv6 which has built in crypto.

I am holding my breath.