A honeypot is an information system resource whose value lies in unauthorized or illicit use of that resource. A honeytoken is no different. It is a small snippet of data that sets off alarms whenever it is used. Jeremiah Grossman brought this to my attention in regards to using it within the “Matrix security model” I discussed last week. Honestly, I’ve used this technique in the past, but it makes a lot of sense in the context of a Matrix security model where you can seed your database with information that when “used” it sets off alarms.
In this case, the term “used” is actually probably too strong a word. You could actually detect that the information is flowing out of your own network using either a database access teir or a packet inspection device that sits between your web application tier and the SSL accelerators (if you have them). In this way you would be able to detect that the information that is stored in you database (and should never be accessed) was, in fact, transported off of the database machine and out of the network. This is an area of database security that could easily be overlooked.
Additionally you could set traps inside of the application itself to watch for users who attempt to log in with the information they might derive from your host. All then creating signaling to your application to alert on-call security operations teams as well as initiate the Matrix for the session that created the honeytoken account. This way you can track the users as they traverse your application and see what they are actually interested in doing with the accounts, giving you insights without actually risking any other users’ accounts.
The Matrix security model still has tons of problems, and I don’t recommend it’s use without dealing with those issues, but this brings it one step closer to being a viable and useful application defense measure.