Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security

Honeytokens: The Other Honeypot 427

Posted by CmdrTaco from the something-to-think-about dept.
martyros writes "I just read a fascinating article by Lance Spitzner securityfocus.com about a concept he calls honeytokens. The idea is similar to that of a honeypot, which he defines as "an information system resource whose value lies in unauthorized or illicit use of that resource". Rather than having a computer that's designed to be broken into, however, you have say, a record in a database or a file has no legitimate use; ergo, if anyone uses it, it must be illegitimate. An example he gives: adding a record to the hospital database for a guy named "John F. Kennedy". It doesn't correspond to a real person, so no one has any business looking at the file. If someone does access it, you know that they're abusing their privileges somehow. The article has several other clever examples, which I found very thought-provoking."
This discussion has been archived. No new comments can be posted.

Honeytokens: The Other Honeypot More

Honeytokens: The Other Honeypot

Comments Filter:

  • Or they made a mistake (Score:3, Insightful)

    by buffer-overflowed ( 588867 ) on Thursday July 17, 2003 @06:01PM (#6465834) Journal
    Or there's a flaw in your software.

    Or they were poking around bored.

    Or you've been hacked in which case you won't have an access record anyway if the hacker did their job right.

    Yes, quite superior to a honeypot, in every way.

    • Re:Or they made a mistake (Score:5, Insightful)

      by in7ane ( 678796 ) on Thursday July 17, 2003 @06:08PM (#6465903)
      I agree, it's just too likely that it will be people from within the organization just 'poking around' with no ill intent.

      It's just human nature - same as having to open a box with the sign 'do not open' on it :)

      Add to this that authorized workers will likely be told about these and told to keep out - causing a flood of 'I wonder what's in there...'

      • Re:Or they made a mistake (Score:5, Informative)

        by timmyf2371 ( 586051 ) on Thursday July 17, 2003 @06:32PM (#6466139)
        The UK's Data Protection Act is designed to stop things even like this.

        Employees within an organisation should not be accessing records about a customer/patient without the client's consent - ill intent or no ill intent.

        Particularly records such as hospital records - staff should under no circumstances be accessing records for any person, ie John F Kennedy, unless required by the customer/client/patient.

        If employees are poking around in files which are designed to trap them, what is to say they're not poking around in your records without your consent - is this breach of privacy acceptable to you?
        • If employees are poking around in files which are designed to trap them

          this is vaguely reminiscent of the trivial pursuit case. basically a guy wrote lots of trivia books and was worried about ppl "stealing" his trivia facts for their own competing trivia books. so he planted a false bit of trivia (that columbo's first name was philip) and waited for someone to copy it. and trivial pursuit were the ones who did and they promptly got sued. of course the case got thrown out of court (you copy one person it'
        • So the JFK record would have to be corrupted, because if it emulated a correct record, then when the senior ward supervisor (nurse) was rostering staff to look after patients, JFK would be selected and allocated automatically. You'd have to fake all the way up to the top, ie ward, doctor, everything. And then the staff would recognise it as fake. Hospital patient databases are mostly for making sure patients get the right treatment, and a legal record of that treatement, and a financial record of the cos

    • Re:Or they made a mistake (Score:5, Interesting)

      by captain_craptacular ( 580116 ) on Thursday July 17, 2003 @06:10PM (#6465921)
      I agree, the database example is especially bad.

      It's very easy for beginners to write erroneous SQL which will access every record in a table.
      There are also lots of situations in SQL in which you legitimately need to access every row in a table, or in which the database does so on your behalf.

      For example:
      If you have a non-indexed table called Names. and you do select * from names where last_name = 'Smith'. Every row will be looked at. Legitimately.

      • It's very easy for beginners to write erroneous SQL which will access every record in a table.

        Not just beginners. Half of the reporting and maintenance querries are likely to hit their trick records. They'd be constantly responding to false positives.

    • Either way (on the first two examples), it would be usefull to know you had a flaw, or that there were bored employees perusing patient files.

    • Re:Or they made a mistake (Score:5, Insightful)

      by highcaffeine ( 83298 ) on Thursday July 17, 2003 @06:17PM (#6465981)
      I was going to mod this down (overrated), but decided I'd rather reply.

      No one said that honeytokens are superior in every way to honeypots and should be used in place of the latter. That you pulled out of your hindquarters. Basically, what you said could be expressed similarly in this example: "Seat belts are not absolutely superior in every way to the steel frame of a car, so what's the point in buckling up?"

      I would hope that makes it clear how faulty your logic is. Like using seat belts in addition to a protective steel frame, to provide added protection, honeytokens could be used in addition to honeypots. Their ultimate goals are the same: protect your life (frame/seat belts) or your data (honey[pot|token]). If your life/data is that important, why not provide all the layers of security you can?

      One advantage that honeytokens do have is in who they can help protect against. Honeypots are typically deployed to detect and help figure out how to protect against external threats. Anyone with a shred of sense about security knows, however, that you also need to protect against internal threats. Deploying honeytokens can help in that vein, by posssibly detecting internal abuse of your systems.

      Just because honeytokens won't protect against everything, solve global hunger, and bring about world peace, doesn't mean they shouldn't or can't be used effectively.

      • Re:Or they made a mistake (Score:5, Interesting)

        by antirename ( 556799 ) on Thursday July 17, 2003 @07:43PM (#6466623)
        Here's what I've been doing for years. I have folder on my drive with a very suggestive name. Looks like porn... a few really good videos, some nice pic series, a few porn games, the usual stuff but fairly high quality. This folder is sure as hell not in any area that the webserver or anything else connected to the web should be able to touch, it is in a fake user's directory. The last few .exe files on the list are not porn games, though. At least that's not all they are. They've had some rather nasty viral code (not in the GPL sense) wrapped into them. The only way those files will ever be accessed is if the box has been compromised or I really screw up running as root (which would corrupt my logs, but otherwise do nothing since the box is *nix). Those files have been accessed once. I screwed up and didn't apply a patch I should have. The script kiddie, on the other hand, went off the radar a few minutes after those "special" files were downloaded. Yeah, I had to rebuild the machine to be safe (faster then figuring out how much damage the little fucker did and I really didn't care who he/she/it was), but at least I got some satisfaction out of it :) Now, this part is of course purely hypothetical, but maybe something like this could be used to "poison the well" on those PTP networks the RIAA is trying to monitor. There are .exe compression programs out there that do a GREAT job of convincing antivirus software that a piece of software doesn't REALLY contain something like, say, Chernobyl. If you run MS shit on your box (or have a gaming box running MS like I do), give it a try for your own amusement. Then, when you're done, give the hype about "sandboxes" and "heuristics" some thought. Of course, script kiddies don't always run antivirus software, but why not be thorough? Fuck 'em if they can't take a joke.

    • Re:Or they made a mistake (Score:5, Interesting)

      by aafiske ( 243836 ) on Thursday July 17, 2003 @06:17PM (#6465988)
      "Or they were poking around bored.

      Or you've been hacked in which case you won't have an access record anyway if the hacker did their job right."

      Well, for point one, if someone is bored and is poking around a medical database, that's a problem. And someone using a honeytoken credit card number is never okay. It's not something you do because you're bored.

      And the hacker might have compromised one system and gotten data, but the point is that you put some fake data in there as well. So then hacker says 'hooray, I've gotten the CFO's password, let me go check out some interesting numbers in their computers' and suddenly they're caught red-handed, because that login doesn't exist in reality, and the computer in question is set up to notify people immediately on a honeytoken login.

      These examples are taken from the article. It's a pretty clever idea and is much more versatile than the idea of a honeypot just as a server.

    • Or they were poking around.... (Score:5, Interesting)

      by autopr0n ( 534291 ) on Thursday July 17, 2003 @06:19PM (#6466008) Homepage Journal
      Or they were poking around bored.

      Or there's a flaw in your software.

      Well, then you'll just end up with a record of an 'intrusion' from localhost. if there is something wrong with your software, you should fix it anyway.

      Or they were poking around bored.

      The whole point is that they shouldn't be poking around. I certanly wouldn't want hospital employees 'poking around' in medical records. If someone is 'poking around' in sensitive data, then they are a hacker. If it's someone from your organization, you should either bitch at 'em or fire 'em, depending on what kind of work you do.

      Or you've been hacked in which case you won't have an access record anyway if the hacker did their job right.

      Not if you burn logs straight to a multisession CD...
    • There are lots of applications where poking around bored is unacceptable; Medical, Financial, Law Enforcement, National Security to name the first few that come to mind.

      I personally don't want the system administrator at my Doctor's office browsing my health records or random people at my bank browsing my financial information.

      • Re:Or they made a mistake (Score:5, Interesting)

        by IWannaBeAnAC ( 653701 ) on Thursday July 17, 2003 @06:56PM (#6466292)
        Interesting. I would have expected that "national security" is one of the few places where 'random' poking around, following up idle speculations etc. is absolutely worth doing, because you might uncover something important.

        I can see this might be a problem in the USA though. In mosts countries, the secret services have nothing to do with law enforcement so a spook coming across a record that showed minor suspicous (in a criminal sense) behaviour, as long as it has no national security implications, would just ignore it. Unfortunately, in the USA, the agency likely to be doing the (illegal) snooping is the one and the only FBI, it means that (1) the national security has its hands tied by being constrained by procedures designed for ordinary criminals, and (2) procedures that ought to be use ONLY for serious national security (eg echelon?, unauthorized wiretaps etc) get misappropriated for urban law enforcement.

    • Re:Or they made a mistake (Score:4, Interesting)

      by singularity ( 2031 ) * <nowalmart.gmail@com> on Thursday July 17, 2003 @06:21PM (#6466034) Homepage Journal
      Or they made a mistake

      Yeah, no employer would want to know about accidental DB access...

      Or there's a flaw in your software.

      Yeah, I *definitely* would not want to know about that.

      Or they were poking around bored.

      Once again, no employer would want to know about curious poking-around by employees.

      Or you've been hacked in which case you won't have an access record anyway if the hacker did their job right.

      Yeah, not worth it to take 30 seconds to make up a false record, since *every* cracker covers their tracks perfectly.

      Yes, quite superior to a honeypot, in every way.

      Different tools, different uses.

    • Re:Or they made a mistake (Score:5, Insightful)

      by dasmegabyte ( 267018 ) <das@OHNOWHATSTHISdasmegabyte.org> on Thursday July 17, 2003 @06:22PM (#6466038) Homepage Journal
      Ok -- I think this isn't necessarily a bad idea, so long as you don't expect it to be the end-all, be-all of security. I often perform wierd ad-hoc queries on tables for data mining purposes, or to help our support team do things that their program just won't do (like cross index reports for a list of ids).

      Some DBAs LOVE to think that their precious data is only access the way they want it to be accessed. I once had a guy tell me, flat out, "You guys should never be doing ad hoc queries. Write and submit a stored procedure for everything you do." I have never heard a more ivory tower asshole statement in my life, and you better believe I didn't listen for a second. Nor should I have, nor would he really want me to...when the CEO comes over and asks for usage statistics for a potential customer, he doesn't want to be told "Wait until the DBA shmuck reviews this query first." It becomes harder to justify your excessive salary when all you do is prevent us programming peons from doing our job and call it "security."

      If I pull up a honeyrecord, and you're my dba, you should ask me about it, but not assume my account has been hacked and lock it down. Which means this is nothing more than yet another check measure. You'll still have to eye your logs and know your system.

      You know, this is actually a great way to prove somebody from outside has been data mining, and prosecute them for it. Put bullshit data in your db. If it shows up on somebody's website as fact, you'll know they were grabbing your shit. Producers of maps do similar things...invent dead end streets and place them where nobody will ever try to go. If you look at somebody else's map, and you find your BS street, you know they plagarized. Just make sure you never buy a house on that street. Heh.

      • Re:Or they made a mistake (Score:5, Informative)

        by questamor ( 653018 ) on Thursday July 17, 2003 @06:34PM (#6466157)
        Producers of maps do similar things...invent dead end streets and place them where nobody will ever try to go.

        When I worked in mapping, this is exactly what we did, and we kept a database of the false information and could check quite quickly if another supplier's dataset matched ours, "bug for bug"

        The false street is one, and is used in products where an extra nonexistent street wasn't something that could have problems with the use of the map in particular. There are dozens of other methods for different datasets, depending on their use. That's been going on for decades in the mapping industry.
    • Or they were poking around bored.

      If so, they deserve to be fired. Boredom is not an excuse for violating patient privacy.

    • "Yes, quite superior to a honeypot, in every way."

      Nitpick nitpick nitpick.

      All this negativity because the intentionally vague yet illustrative example didn't pass the "can I poke a hole in it?" test.

      The concept is sound. It just requires a little creative thinking to make it work in your own specialized case. Try putting energy into making the concept work instead of pointing out the flaws in the illustrative example.
    • Or there's a flaw in your software.

      Or they were poking around bored.

      Or you've been hacked in which case you won't have an access record anyway if the hacker did their job right.

      Yes, quite superior to a honeypot, in every way.

      It's not superior it's a tool. You wouldn't want to ignore any tool, would you? Any of the above things are REASONABLE flags for you to have a look-see... maybe not get crazy, but at least look around.

      Would you NOT want to know about flaw in your software?

      Would you NOT w

  • Popular anti-spam technique (Score:3, Interesting)

    by Anonymous Coward on Thursday July 17, 2003 @06:01PM (#6465835)
    I seed all my pages with special "token" email addresses that will only be found by a spammer using harvesting software (or a really really bored user). Normal people will never find it and never want to use it. It works amazingly well.

    • Re:Popular anti-spam technique (Score:5, Interesting)

      by Greedo ( 304385 ) on Thursday July 17, 2003 @06:22PM (#6466048) Homepage Journal
      Even better (IMHO) is a system I developed for dynamic pages.

      Each page is seeded with a random, unique email address. Also, that address is stored in a database, along with the time it was generated, the page it was displayed on, and info about the viewer (i.e. IP address, UserAgent, etc.).

      Then, if that email is ever used, another automatic system reads that data out of the database and can correlate it.

      It's interesting to see some things. Like how long after an email is harvested is it being used (as little as 4 hours), and whether the people harvesting are also spamming (usually not). This way, you can fight spam by attacking/blocking the spammers *and* the people doing the harvesting.

      Oh, and I claim prior art ... in case Bezos is reading this.
    • I do the same thing, except I harvest e-mail addresses from slashdot and post those.
    • What does this do besides generate spam for the "token" address?

    • You and a good many anti-spammers. I have a bunch of friends that have spamtrap addresses on web pages in "blind links" -- links that enclose no text or graphics. They can't be accessed by normal web browsers, but spammers using software to scrape the web for email addresses get them just fine.

      Blind spamtrap addresses aren't entirely foolproof. There are a few kooks who deliberately look for addresses in blind links or known to belong to other anti-spammers and feed them to web sites. But blind spamtra

  • Nothing new here, move along (Score:5, Informative)

    by ebh ( 116526 ) * <ed.horch@org> on Thursday July 17, 2003 @06:02PM (#6465841) Journal
    This sort of thing has been around for decades. I remember as far back as the early 1970s, hobbyist magazines' "Buyer's Guide" issues would have deliberately bogus entries to ensure that their competitors didn't steal the data wholesale for their own buyer's guides.

    • Re:Nothing new here, move along (Score:4, Funny)

      by AndroidCat ( 229562 ) on Thursday July 17, 2003 @06:15PM (#6465975) Homepage
      Encyclopaedias have done this for ages too. Make up a boring tiny entry for .. Boring Arkansas, and wait for a rival to copy it, then sue them. (Appologies if there is a Boring Arkansas, I am so sorry for you.)

    • > This sort of thing has been around for decades. I remember as far back as the early 1970s, hobbyist magazines' "Buyer's Guide" issues would have deliberately bogus entries to ensure that their competitors didn't steal the data wholesale for their own buyer's guides.

      I actually did it on computers a decade ago, and I doubt that I was a groundbreaker even then.

      Already by then VMS provided ACLs and a very sophisticated security monitor that you could program plugins for ("plugin" for lack of a better t

    • Re:Nothing new here, move along (Score:5, Informative)

      by throwaway18 ( 521472 ) on Thursday July 17, 2003 @07:06PM (#6466353) Journal
      >This sort of thing has been around for decades.
      Reputedly this technique has been used for log tables since the seventeenth century.

      A few hundred years before the invention of the electronic gadgets slasdotters take for granted people were navigating the world in sailing ships and calculating thier longditude and latitude with a sextant to measure the angle from the ground to the sun or a star, a clock and a book of log tables. Napier produced log tables in the 1600's but an accurate shipboard clock was only invented in 1764.

      A book of log tables can be used to multiply integers quickly using A*B=antilog(log A + log B) or to calculate triginometic funcitions like sine, cosine and tan.

      Original production of a book of log table took a lot of mathematical work. Publishers reputedly seeded the books with errors in the last digit to catch copiers. Link [mathforum.org]

  • Nothing new (Score:2, Interesting)

    by deman1985 ( 684265 )
    I've used the same concept before on my work computer. I plant suspiciously named files on my desktop or (usually) less obvious places so if someone tries to search my computer and comes across this file, reports its contents, and I hear about it, I know it's time to change my password ;)

    • Re:Nothing new (Score:3, Informative)

      by dnoyeb ( 547705 )
      Me too. especially email. I have an address in my address book with the name of

      "This mail was send by virus"

      something like that, and I expect the email to bounce back at which point I know I have been infected.

      also people have been hiding email addresses in web pages to test spammers for a while now.
    • David, is that you?
      When I got my first admin job (first root password) my boss did something like this. He had open perms (755) on his home dir, then a private dir (700) with a file named .sex
      He also had a cron job on another box that checked last-access-time for the .sex file.
      My sense of ethic has come along way since then, in part because of the (perfectly reasonable) way he talked to me when I got caught.
      DavidH, if you ever read this, thanks again.

      --

  • Just like "ringers" (Score:5, Informative)

    by vegetablespork ( 575101 ) <vegetablespork@gmail.com> on Thursday July 17, 2003 @06:02PM (#6465852) Homepage
    Folks who rent mailing lists add "ringers," which, if they receive a mailing after the term of the rental is up, yield prima facie evidence of violation of the rental contract.

    This is an interesting use of a known technique to help detect the unauthorized use of data, and alert administrators that the barn door is open--and maybe even who opened it.

    • Folks who rent mailing lists add "ringers," which, if they receive a mailing after the term of the rental is up, yield prima facie evidence of violation of the rental contract.

      I can't think of a single legitimate reason to 'rent' a mailing list.

  • Search? (Score:3, Interesting)

    by ajiva ( 156759 ) on Thursday July 17, 2003 @06:03PM (#6465854)
    What happens if someone does a search for that happens to find "John F. Kennedy" and several other patients. Does that mean the person was in the wrong place?

    • What happens if someone does a search for that happens to find "John F. Kennedy..."

      Or, God forbid, someone with the name "John F. Kennedy" checks into that hospital.

    • Re:Search? (Score:3, Funny)

      by WindBourne ( 631190 )
      Does that mean the person was in the wrong place?
      Well, yes. He is suppose to be in the Arlington National Cemetary, not a hospital.

  • The problem... (Score:5, Insightful)

    by melete ( 640855 ) on Thursday July 17, 2003 @06:03PM (#6465859)

    The problem with this (and with a lesser degree, with honeypots) is that these tokens will get accessed in legitimate ways -- for example, what if your secretarial staff is creating a mailing list, and "JFK" gets sent something? Or you have a browse function in an application that uses the database?

    It's a good idea, but not a panacea.

    • Re:The problem... (Score:3, Informative)

      by DaveAtFraud ( 460127 )
      Unfortunately, the hospital example isn't the greatest but the idea is to add such a record with contradictory information such that known/legitimate uses of the database will not extract it. In this case that might be setting both the "is a patient" and the "deceased" indicators to true or "discharged on" and "in room number" fields or showing the patient as being in a non-existant room. This approach works best when designed into the data from the start since checking multiple, supposedly redundant fiel

    • Re:The problem... (Score:2, Interesting)

      by mindstrm ( 20013 )
      You generally work around it. It's not as simple as "was this account accessed". I mean, you can track that on legitimate accounts.. you don't need fake ones..
      but inserting fake addresses into the customer database, with fake credit cards and whatever so that you can tell when your database has been compromised, or otherwise, is a good idea, and has been done by many smart people for ages.

      If the secretarial staff sends a message to that user, you'll know where it came from, and won't have a problem with i
  • An example he gives: adding a record to the hospital database for a guy named "John F. Kennedy". It doesn't correspond to a real person, so no one has any business looking at the file.

    Of course, there are some places [utsouthwestern.edu] where "John F. Kennedy" is a perfectly valid database entry. Actually, it's a database entry for which a lot of people make it their business [jmasland.com] to look at the file.

    Which, I suppose, shows exactly why the Honeytoken concept makes sense...

    • A woman I knew since grade school got a job in American Express's credit card clearance center in New York in the 80s. Seems some of her colleagues would spend hours every day looking for celebrities' credit card records just so they could gossip (back then the system was less automated than it is now, and an actual person would need to verify that a charge was valid in many more cases than today). I'm sure that this kind of thing still happens. Putting in bogus entries with celebrity names would catch s

  • Yes, this is old news (Score:3, Interesting)

    by brooks_talley ( 86840 ) <brooks@noSpam.frnk.com> on Thursday July 17, 2003 @06:05PM (#6465883) Journal
    Yahoo (and presumably other search engines follow suit) keeps some bogus entries in the DB so they can detect someone stealing their whole DB.

    Some print newspapers run bogus classified ads so they can detect a competitor trying to bulk up their own classified section.

    Some anti-spam companies post to newsgroups specifically to get addresses harvested; any email to those addresses is the sign of a spammer.

    Handy, but hardly breaking news. Might as well run an article about a researcher discovering the usefulness of packet switched networks.

    Cheers
    -b
    • Some print newspapers run bogus classified ads so they can detect a competitor trying to bulk up their own classified section.

      Heh. And what do they do when they find out? Classified ads are hardly gonna be copyrighted material. Even if they were, I can't see the advertiser being anything other than happy about the free advertising in an extra newspaper.

    • Forgot about the ICANN whois database? It's just full of bogus records. The honey is bountiful and overflowing :-)

  • RIAA Using HoneyTokens (Score:2, Interesting)

    by Anonymous Coward
    Another good example would be the RIAA putting bogus music files on P2P networks. For example, if you query and download a file that is named "Metallica - Enter Sandman.mp3" then chances are you have other files that are of dubious lineage.
    The sword here cuts both ways, unfortunately.

    ----
    Like listening to music? Then use Fission [sidespace.com], the MP3 player with a brain!

  • I do this already (Score:5, Funny)

    by L. VeGas ( 580015 ) on Thursday July 17, 2003 @06:08PM (#6465904) Homepage Journal
    By placing arsenic in your water bottle that you leave in the refrigerator, you can tell who's been pilfering your lunch.
    • By placing arsenic in your water bottle that you leave in the refrigerator, you can tell who's been pilfering your lunch.

      I prefer to use a bottle of honey. You catch more people that way. I even tried vinegar, but honey works best :)
    • You can solve this problem by labeling your lunch "Meat Experiment."

      Similarly, you can label your beverage "Fluid Excretion Experiment."

    • Re:I do this already (Score:4, Funny)

      by dschl ( 57168 ) on Thursday July 17, 2003 @06:38PM (#6466188) Homepage

      I have heard stories of leaving gloves dusted with dye powder (same stuff used in money shipments) in your locker, just for the glove-thief on drilling rig crews. You always know who is stealing your gloves, but the bright red hands of the thief let everyone else know, too. If you are feeling a little bit nastier, you dust the inside of the glove with caustic, and then leave it in your locker for the glove thief. The caustic is a bit more dangerous, because if he rubs his eyes just before his fingers start burning, it could cause severe eye damage.

      The lunch thief in my drilling crew was the motorman, who did five years in Kingston pen for armed robbery. Claimed he was "reformed", so I guess he didn't really consider sandwich theft to be much of a crime. I was tempted to add ex-lax or something worse just for him, but never got around to it.

  • Been around for awhile (Score:5, Funny)

    by miyako ( 632510 ) <miyako AT gmail DOT com> on Thursday July 17, 2003 @06:08PM (#6465908) Homepage Journal
    ...several years in fact, although in a different form.
    A while back a bunch of businesses created a website called slashdot to monitor people who were surfing the net instead of doing work.

  • This is new? (Score:4, Interesting)

    by shamino0 ( 551710 ) on Thursday July 17, 2003 @06:08PM (#6465910) Journal
    I seem to remember that phone companies have been doing this for decades in order to catch people illegally copying the phone book.

    Phone listings are not proprietary - anyone can publish a phone book. But you can't copy someone else's publication (like the telco's official phone book.)

    In order to tell if a third-party phone book is legal or not, the telcos put a bunch of bogus listings in ever one. When third-party books are published, the telco can check to see if the bogus listings are in it. If they are, then they know that the book is an illegal copy of the telco's phone book. A book that doesn't pirate the telco's book (e.g. using listings purchased from the telco or by asking people to contribute contact information) will not have those listings in it.

    This sounds like the same concept applied to a new purpose.

  • I can see someone accessing a record just because it's interesting.

    A bored nurse at a hospital is browsing through patient files, sees "John F. Kennedy", and for shits and giggles, opens the record to see if he had a gunshot wound to the head.

    Same if you call it "Bwana Guana the Flying Butt Monkey", or hide the file, or someone notices that it hasn't been accessed since last year, etc.

    • But the point is that under HIPAA rules, browsing that information and pulling it up if you don't need to is illegal. RTFA. You'd be violating Mr. Kennedy's rights to have private records.

      Similarly, lookng up the names of baseball players, movie actors, or any other celebrities is illegal. No one has the right to anyone else's medical records unless they have a specific need, specifically to provide healthcare or accurate billing.

      They're very strict about that, otherwise you end up with hospitals selli
    • A bored nurse at a hospital is browsing through patient files, sees "John F. Kennedy", and for shits and giggles, opens the record to see if he had a gunshot wound to the head.

      I don't think Nurses are supposed to be able read through random people's medical files out of bordom. There are all kinds of crazy regulations required by the HIPA or whatever for handling medical information in the US as it is.

    • That's the whole point: this is a technique to catch your staff when they do something that they are not supposed to (like violate the privacy of celebrities). These things don't stop at shits and giggles: if someone gets at a rich man's financial records, that someone can then engage in identity theft, or sale of embarrassing gossip to tabloids, or fanboy/fangirl invasion of a sick person's hospital room, etc.

  • Fred Saberhagen describes using a Honeytoken to defeat an enemy in one of his Berserker stories. Apparently it's an old Dictionary & Encyclopeadia Publishers trick to prevent plagiarism. they put in a number of reasonable entries that nobody's ever going to need, and if anybody copies them, they know they've been plagiarised, and can prove it in court

    'He copied our encyclopaedia, and we know this because he has entries we made up out of whole cloth.'

  • Telephone companies have been doing this for years.

    They list bogus entries in phone books and then scan other lists for occurrences of these entries. Subscriber lists and customer information is copyrighted and non-freely-distributable, supposedly (these terms may be slightly wrong).

    If they start showing up in other databases (like other companies' phone books), calls are made. It's an excellent way to prevent the copying of their property en masse.
  • When I fill out forms or give out personal information, I will deliberately put in some erroneous data. For instance, putting X as my middle initial or putting an apartment number on the address for my house. Now when I get junk mail I can figure who is selling or giving away my information and stop doing business with those entities.

  • These are just another tool, which when employed with other layers of tools, *may* help provide you some circumstantial evidence of malintent.

    As noted in other comments, if you just put in some trigger to notice on the database system itself if anyone access JFK's record - well, if the database system is compromised, the trigger can be bypassed as well. It will catch only "legit" accesses without system compromise - as in someone pulling the record through a normal interface such as a hospital records app

  • As has been pointed out in numerous replies, this practice has existed for decades if not centuries. The earliest version I am aware of was done by Almanacs and Encyclopedia's. Unindexed and uncross-referenced articles would be inserted on the theory that nobody except a copier would find them.

    So all veteran /. readers should be awaiting a story on the issuance of a patent covering the technique.

  • I first saw it mentioned at Black Hat 2002 in Vegas last year. The idea was that you would create fake session tokens for web applications and then monitor them for access by applications trying to brute force the session token values.

    I mentioned it to a web developer who said that the idea has actually been implemented in some of the large e-commerce sites he's worked on.
  • This idea sounds good on paper, but won't work in practice.

    Here's the flaw... how does the system know when data is being accessed illegitimately? Just because there's a dummy record in a database, doesn't mean that it won't be accessed. The example given with the patient table fails to account for times when the software itself will access the data for various purposes ... updating information, reporting, etc.

    Exactly how would one go about monitoring data access? In theory, it's simple ... enable some
  • I worked for one of the largest shareware catalog companies (yeah, way back then, my first job :), and had to write software that would come up with the reports of what customers were interested in, when they last purchased, etc. etc. etc.

    Whenever our company would sell this targeted list of previous customers to other companies, they would also insert several bogus names that led back to our owners. Each name was setup to recieve a particular piece of junk mail. This list could only be used by that compan

  • One note on false positives "problem" (Score:4, Interesting)

    by Nemus ( 639101 ) <astarchman@hotmail.com> on Thursday July 17, 2003 @06:24PM (#6466070) Journal
    Some people have pointed out that maybe someone just looking through a database on legitimate business sees an interesting patient file, and opens it up, just to look.

    One reason this idea would be especially good for hospitals is because such actions have gotten hospitals sued in the past. Simply put, no hospital employee is supposed to view a patient's information unless required. So, if Nurse Betty is looking up "John F. Kennedan's" file, and also sneaks a peek at "John F. Kennedy's", she just broke federal law, and the hospital is going to want to know about that.

    As for false positives in other instances, people seem to be just trolling. For example, every single day at a former employer of mine, a cell phone provider, we'd get false positives on customer who may or may not have been using fraudulent information to sign up for service. As such, we would stop and call the verification services we used, and verify that customer. So sure, out of thirty customers a day, it would generate five warnings, four of which were false. But one of them wasn't, and that makes all the difference.

    Theres never going to be some "All seeing Eye of God" security system, but every little bit helps. Especially, as noted, in both banking and hospitals, where customer's information is bound to a need-to-know basis by federal law.

  • Dictionaries, maps, and many books have included these things for decades, perhaps centuries. Most modern maps have tiny errors that are intended to be insignificant except as copyright "markers". Dictionaries contain false entries intended to serve as markers and preserve the collection copyright. Many books (especially editions of public-domain works or collections of multiple works) contain deliberate (originally not-so-deliberate) typos that mark the particular edition.

    As far as I can tell, "honeyt

  • I can imagine this reaching some level in intranet circles. This is not a new idea.... In fact, it's far more common in real life. You know, social engineering and all that stuff. As a quick example, the only thing memorable about "Eyes Wide Shut" was the "musican's password" goofup.

  • Old, old idea. (Score:5, Informative)

    by DdJ ( 10790 ) on Thursday July 17, 2003 @06:30PM (#6466120) Homepage Journal
    People have been doing this for ages, at least out here in the "really real world".

    Mapmakers put fake cities on their maps in obscure places, so that they can tell whether another mapmaker just copied their maps (illegal) or whether they went out and compiled their own information.

    Folks who put together directories (like phone books) that forbid their use by telemarketers put fake people (with real phone numbers) in there to identify telemarketers that are illegally using the directory as a basis for telemarking calls.

    There's even a sort-of-backwards example from cryptography, that I believe Schneier came up with. You are all probably familiar with the basic concept that if you crack someone's crypto, you can't use the info you get from cracking their crypto unless you can plausibly explain how you got that info by another mechanism. There are big chunks of Cryptonomicon dedicated to this idea, and it's a real idea. Well, one way to tell if your crypto has been hacked is to find a really funny joke and to transmit it only by your crypto mechanism. Most folks who'd crack your crypto would have a hard time believing that the cleartext of the joke was never transmitted anywhere, so they see less reason to be anal about the normal procedures. So, you watch to see if the joke "leaks out" into the world. If so, and if you maintained other security, then your crypto has been broken.

    You'll find all sorts of examples of this basic idea, going back for centuries.

  • Wise detected pilfering info from Installshield (Score:3, Informative)

    by raaum ( 152451 ) on Thursday July 17, 2003 @06:35PM (#6466162) Homepage

    basically because of a honeytoken like entity

    someone at installshield had an entry in some internal company data source using her maiden name (and had used her maiden name nowhere else). she recieved solicitations from wise and got suspicious.

    now installshield is sueing the hell out of wise, see this article [findlaw.com], and this news release [installshield.com]

  • When I first got broadband, I had a machine that had NOTHING pointing to it, other than a random DNS name that you had to know about in order to look at it. (blth23845x.bchai.hsadsl.bctel.net or something like that). I started a Web server, and watched the logs -- knowing that ANYBODY who connected to my machine was doing it as part of an IP range scan.

    I automatically generated reports on that basis.

    I also generated reports for probes to some of the other 'nasty' ports.

  • Hi Slashdot People! (Score:6, Insightful)
    by John F. Kennedy (666) on 2003.07.17 16:38 (#666)

    I love Windows! It never crashes. Linux Sucks. Hilary Rosen is having my baby. Filesharers are evil. Lessig is a communist. Matrix Reloaded Sucked. The Twin Towers Sucked. Online gamers are asocial dweebs. No, you cannot make a beowulf cluster of these. Nothing like this whatsoever happens in Soviet Russia.

    [ Reply to This ]

    666 replies beneath your current threshold.
  • This sounds similar to (but distinct from) the Canary Trap that Tom Clancy described in one of his novels. I think it was "Cardinal of the Kremlin," though I may be wrong. I don't know if the idea was Clancy's originally, but that's where I saw it. Basically, each copy of a classified report has various meaningless differences, like an intentional misspelling or use of a different phrase. Each person is given a slightly different and unique version of the report. If it ends up being leaked, it's relati

  • This is a great idea (Score:3, Interesting)

    by faust2097 ( 137829 ) on Thursday July 17, 2003 @06:52PM (#6466277)
    One place I worked at had 'root' as a honeytoken on all their production servers, there was a separate administrator account [they never would tell me what its name was...] and if anyone logged in as root it set off all sorts of alarms. I thought that was cool.

  • fake files on kazaa??? (Score:5, Informative)

    by pair-a-noyd ( 594371 ) on Thursday July 17, 2003 @07:04PM (#6466343)
    Aren't all those fake files on the p2p networks honeytokens??

    They are lures, if you bite then you are doing something illegal and they get your IP address just for biting the bait???

    Bam! Nothing to it...

    I've ALWAYS suspect this..

  • Not exactly revolutionary... (Score:3, Insightful)

    by nmg196 ( 184961 ) on Thursday July 17, 2003 @07:07PM (#6466360)
    Not exactly revolutionary... This is just list seeding.

    You shove in one-time known fake name into a mailing list (postal or e-mail) that you sell and then if any mail arrives at that address sent by someone you didn't sell the list to, then you know that they've been abusing their terms for use of the list. I do the same thing with websites... I register for websites I write with sitename_seed@mydomain.com and if any of the 'seed' addresses get mail, then I know that someone's been harvesting addresses from that site. Thankfully this has never happened (yet!).

  • Credit cards and SSNs? (Score:3, Insightful)

    by sakeneko ( 447402 ) on Thursday July 17, 2003 @07:26PM (#6466493) Homepage Journal

    If you go making up honeytoken credit card numbers and social security numbers, you'd better be sure they *are* bogus, not real numbers that belong to someone you don't know. Otherwise, your honeytoken might be someone's real data....

    Oops wouldn't cover it in that case. <wry grin>

  • you mean like cddb? (Score:3, Interesting)

    by Foresto ( 127767 ) on Thursday July 17, 2003 @07:57PM (#6466704) Homepage
    This reminds me of the cddb [cddb.org] being stolen by Gracenote. Last time I checked, they were still claiming to own the database of audio discs (they may have changed their tune by now), despite the fact that it was built mostly from submissions by people like me. Gracenote basically took our diligent work, and started restricting access to it in order to make money. How do we know that they didn't build their own database? Because it contains entries for unpublished CDs that don't exist outside the homes of a few specific people; effectively honeytokens.

    (Fortunately, an alternative [freedb.org] now exists.)
  • French engines are fitted with a myriad of safeties who, once tripped, must be resetted in order for the train to proceed. However, to reset those safeties, you have to break a seal so the broken seal indicates that a safety feature has been tripped.

    So, whenever a careless engineer trips something, he merely writes in the log "deliberately tripped such and such safety to demonstrate it to so-and-so", and no one is the wiser...

  • These errors are called salt. (Score:4, Informative)

    by isdnip ( 49656 ) on Thursday July 17, 2003 @11:13PM (#6467872)
    This is standard process in the database biz, including things like mailing lists and (as others have noted here) maps. The term for it is "salting". Calling them "honeytokens" is applying the wrong seasoning... and treating it as new on /. is also silly.

Slashdot Top Deals

HELP!!!! I'm being held prisoner in /usr/games/lib!

Close