The problem with this advice is that it is not particularly useful.
In the event that your canary account receives a spam message, you will have gained one piece of data: that at some point in the months since you installed the account, it is likely that someone exploited a problem that exposed a table column in your database.
Now what?
You don't know what the bug was. You don't know how far-reaching the damage is. You don't know when the event occurred. There is, in fact, almost nothing actionable about this information at all.
You might be telling yourself two things:
* That, upon learning of the possible breach, you will lock down the security of your code and your site. Of course, think for two more seconds and realize this is ass-backwards; if you can reasonably lock down your site, you might as well do it before you burn your whole database.
* That, upon learning of the breach, you can get all your users to change passwords. Which, of course, you will never do, because you will be taking an enormous reputational hit over circumstantial evidence, and for the purposes of seeding your database with a couple thousand new passwords for the same attacker to steal.
People like this "canary" and "honey token" stuff because it's fun. But it's not valuable.
If I called you and said, "Hey, would you like me to tell you your site has been cracked?", would you really say "no"? I would argue that the cost of adding a canary is similar to the amount of time that phone call would take.
I'm guessing that after that call, you'd go through your logs and attempt to find out how the site was cracked. Then, if you find some anomalous behavior, you might be able to isolate the component that was being exploited and fix it. Maybe you wouldn't find it, but maybe you would.
What's your point? Sure. Set up a canary account. It won't hurt you. But the only way it will help is if your monitoring regime is already so good that it works with or without the canary.
But wouldn't the "canary" idea be more useful if the email was changed frequently? Suppose a cron job updated the email address every day to include a few non-obvious characters encoding the current date so that the spam you get tells you when that row was copied from your database.
To me it makes sense to keep good records of security events so if I were to get this "signal" I'd make sure the details were captured and the appropriate people informed. Then I'd double check the obvious things like who logged into the database server that day, who had access to backups, who may have worked on database code in that time, when that code was last (or ever) audited and so on.
What if you automatically created a new canary every day with the date in it? Something like something-really-long-xyz-yyyy-mm-dd@yourdomain.com. Then you could find out exactly when your database was stolen. If all canaries up to 2009-01-01 were spammed, and later ones weren't, you'd know they dumped your db on New Year's Day.
All that would tell you is the earliest date your database was compromised and then sold to spammers. If an attacker can harvest your database once, they can do it repeatedly --- which is why warning all your users to change their passwords in this situation is a bad idea.
You are highly unlikely to find your own bugs; teams that have invested millions of dollars in training and process (for instance, requiring detailed internal code reviews before signing off on code to ship, and passing static analysis systems) still have gameovers shown to them during third party pen tests.
In the event that your canary account receives a spam message, you will have gained one piece of data: that at some point in the months since you installed the account, it is likely that someone exploited a problem that exposed a table column in your database.
Now what?
You don't know what the bug was. You don't know how far-reaching the damage is. You don't know when the event occurred. There is, in fact, almost nothing actionable about this information at all.
You might be telling yourself two things:
* That, upon learning of the possible breach, you will lock down the security of your code and your site. Of course, think for two more seconds and realize this is ass-backwards; if you can reasonably lock down your site, you might as well do it before you burn your whole database.
* That, upon learning of the breach, you can get all your users to change passwords. Which, of course, you will never do, because you will be taking an enormous reputational hit over circumstantial evidence, and for the purposes of seeding your database with a couple thousand new passwords for the same attacker to steal.
People like this "canary" and "honey token" stuff because it's fun. But it's not valuable.