Not really security-related, but one related "honeytoken" trick I have done in the past (for wikis, blogs, forum software, etc) is making account activation emails send a fake URL first in the body of the email that is clearly marked not to be clicked by humans as a bot trap.
Then the real activation link is down below that, clearly marked as well.
The majority of spambots and exploit worms, etc, just have a simple regex for parsing out the first "right-looking" link in the activation email to get their account activated.
On one forum I dealt with, this caught 100% of the hundreds of spambots hitting the forum each month.
Kind of interesting that bots can have some of the best captcha-guessing algorithms, but change up a little of the expected flow from the most common and you can quickly notice which visitors are bots or otherwise.
This works for five minutes until the bot-operator realizes the auto-activation isn't working, and writes 2 lines of code to fix the problem. Now you annoy legitimate users, but don't stop bots. That's good for your competition, but probably not so good for you.
Well, it's not what I recommend for major sites or businesses at all, but I can only tell you that this has worked fabulously on forums that get 1 million+ views a month and has been working for more than two years. I didn't expect it to be so effective, either.
As rantfoil said, if you're Yahoo or GMail or some other major site, they'll fix their bot right away. Yet if you're at all below their radar, this is the sort of easy trick that can buy you some time for spam control replanning. This works great for web software that is constantly attacked by generic script kiddie bots. It's a good bit easier than switching entirely to a different system for blogs, forums, wiki, or CMS when your captcha is broken.
Honeytokens work incredibly well for everyone else -- spamming is a game of finding easy marks. And there are enough easy marks out there that spammers would rather pack up and move on to the next target than deal with a determined engineer.
Is the goal to encourage casual developers to try to hack/probe around your site? Or is the goal to fool/deter legitimate hackers?
I think the former is more likely to happen with the tactics mentioned, and the people who want in are going to just be slowed down a tad trying that path before going another route.
I know a lot of curious people who would try to "probe" around those sorts of fake entrances just because they saw them and not because they really cared anything about attacking the site.
Adding unnecessary code in critical-to-security sections of your application, like this article suggests, is not a good way to make it secure. All code is going to have bugs, and the more code you have, the more bugs you are going to have. You don't want those bugs in your session or authentication-handling code, but this article suggests you add more code there... mostly "for fun".
None of these suggestions will help you solve actual security problems that your users will face, like stolen session cookies. Implementing these suggestions might be fun, but it will probably make your app less secure.
> 4. Add “spider loops” ... be nice, and add “NOFOLLOW” tags to not annoy legit search engines too much.
Honeypots are always dangerous because they can end up ensnaring good visitors & bots with the bad. Yahoo, MSN, and ASK all follow links even if the rel="nofollow" attribute is set. One should at least disallow these loops in the sites's robots.txt file.
If you don't set up sessions for users working with wget, curl, etc., you'll also lock out a lot of legitimate users who want a scriptable interface to your site. This goes double if you don't offer any sort of official API.
Refusing to initialize a session for non-browser UAs just invites abuse via agent masking by malicious users, while locking out innocuous and acceptable uses by your real users.
One word of caution about #5 (adding hidden form fields): to the casual developer, this sounds like fabulous advice and, since it's so easy to add to a site, it's often one of the first things added. However, the "gotcha" here is that any form-filling add-on will fill those forms out. Now you are banning/blocking experienced users - not a good thing.
As far as I know most auto form-fillers fill the form based on values in the ID and Name attributes. I.E. The field named 'email' gets an email address.
In my experience if your honeypot field has a nonsensical name or is named something like 'do_not_fill_field' then problems are unlikely to be encountered.
Then the real activation link is down below that, clearly marked as well.
The majority of spambots and exploit worms, etc, just have a simple regex for parsing out the first "right-looking" link in the activation email to get their account activated.
On one forum I dealt with, this caught 100% of the hundreds of spambots hitting the forum each month.
Kind of interesting that bots can have some of the best captcha-guessing algorithms, but change up a little of the expected flow from the most common and you can quickly notice which visitors are bots or otherwise.