

My Top 6 Honeytokens - sucuri2
https://blogs.sans.org/appsecstreetfighter/

======
thorax
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.

~~~
jrockway
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.

~~~
thorax
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.

------
thorax
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.

------
jrockway
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.

------
Sam_Odio
> 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.

[http://en.wikipedia.org/wiki/Nofollow#Interpretation_by_the_...](http://en.wikipedia.org/wiki/Nofollow#Interpretation_by_the_individual_search_engines)

------
rcoder
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.

------
ScottWhigham
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.

~~~
aarongough
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.

