
Honeytokens: The Other Honeypot 427
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."
Or they made a mistake (Score:3, Insightful)
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)
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)
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?
Re:Or they made a mistake (Score:3, Interesting)
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'
Re:Or they made a mistake (Score:5, Interesting)
Re:Or they made a mistake (Score:3, Funny)
patients aren't in the hospital until in DB (Score:3, Insightful)
Re:Or they made a mistake (Score:5, Interesting)
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.
Re:Or they made a mistake (Score:3, Interesting)
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.
Re:Or they made a mistake (Score:2)
Re:Or they made a mistake (Score:5, Insightful)
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)
Re:Or they made a mistake (Score:5, Interesting)
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)
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...
Re:Or they made a mistake (Score:3, Interesting)
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)
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)
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)
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)
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.
Re:Or they made a mistake (Score:4, Insightful)
Listen. Management doesn't mean discouragement. It does not mean banning a person from doing what they need to do because you're too fucking lazy to make it safe. There's a huge difference between indescriminately giving somebody root and letting them run select statements in a database or on a particular set of tables. It's the difference between giving the inventory guy the keys to your warehouse, or letting him run around INSIDE without hassling him every five minutes. I used to work for the records center for the NY Department of Criminal Justice, and they didn't run as tight a ship as some of the UN*X admins I've known. That's because if they denied access to everything like some sysadmins, the "runners" wouldn't be able to pull what they needed, and law enforcement would suffer as a consequence.
Besides, as much as you like to think of it as such, this isn't your system. You may be in charge of it, but chances are you don't use the thing. The customers do -- the customers and the staff who serve them. You may be in charge of it, but you have no ownership over it. You're in charge like the custodial staff is in charge of the toilet.
You can keep the bad guys out of the building with your firewalls and your routers and your proxies. You can keep the idiots in house out of the sensitive shit, back up the data every 17 seconds and dust everybody's keyboards at night for unknown fingerprints. Hell, you can even come up with some cockamamie password policy, like i have to have at least one korean symbol in my password that changes bihourly. Do whatever makes you feel like you actually know dick about security -- just don't keep me from doing my job. If I can't run a query for a troubled customer, we've lost business. If you have to monitor one extra user account for suspicious activity, we haven't lost anything. Not only is creating potholes like this counterproductive, it also doesn't improve security in the least. I've never known an "exploratory hacker" who cared a whit about getting access to a person's read only accounts when it's often just as easy to get root. Why eat hamburger when you can eat steak?
Re:Or they made a mistake (Score:2, Insightful)
If so, they deserve to be fired. Boredom is not an excuse for violating patient privacy.
Re:Or they made a mistake (Score:3, Interesting)
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.
Re:Or they made a mistake (Score:3, Insightful)
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
Re:Or they made a mistake (Score:5, Informative)
Hospital records are supposed to be kept as private as possible. Employees who satisfy their own curiousity without caring whose privacy they compromise should never have be allowed to have jobs where "poking around" in private data is possible.
Re:Or they made a mistake (Score:2, Insightful)
Therefore, having illegitimate data serves almost no purpose except to make it arguably more easy to detect.
You should be able to detect behaviors of this type without resorting to this method.
Re:Or they made a mistake (Score:3, Insightful)
Re:Or they made a mistake (Score:5, Insightful)
Even in the hospital example, what would you do if the office worker noticed something was wrong? Say, there was an obvious typo or something like that, potentially serious if nobody notices. Do you want the worker to be afraid of reporting it?
While I can see the obvious abuse, poking around stuff that you wern't specifically told to poke is the stuff of legends, it would be a shame if society evolved into a "no permission means no look, no touch" attitude.
Sure, I can see that honeytokens can (and are - after all its just a version of the old 'put a marked note in the safe' trick that has been used in one form or another probably forever) be really useful - but it isn't a replacement for TRUST. I wouldn't want to see this applied universally, especially on public networks.
Re:Or they made a mistake (Score:3, Insightful)
I mean, most times I'm supposed to be looking for weird stuff. I mean, right now I have access to info on people that I KNOW would be appalled to find out someone is privy to everything about some private part of their life. I don't get my jollies off it or anything, but there is no way I can fix some of these problems without ever taking a look at the actual data.
Now, I could hack together some access controls,
Re:Or they made a mistake (Score:5, Interesting)
Re:Or they made a mistake (Score:4, Informative)
Re:Or they made a mistake (Score:3, Insightful)
Re:Sorry-ass bosses. (Score:5, Insightful)
The big guys don't need to steal to drain the company. The laws (and corporate policies) allow them to do things the rest of us would spend hard time in the federal pen for.
As a trivial (though not unusual) example, at my previous job, the CEO made a bad call about handling a bug in a customer's software. Relatively minor bug, but due to the nature of the software, he and the company might actually have had to endure criminal proceedings if they handled his bad call poorly.
So the solution? He left the company with nearly a ten MILLION dollar parting bonus, sort of vaguely admitted responsibility, regulators considered the matter suitably dealt with, and the problem went away.
Think about that... This guy broke the law, so they gave him millions of dollars.
And some folks wonder why so many of us outright despise corporate America.
As Eric Idle once said, after killing a dozen or so tribesmen in Monty Python's "The Meaning of Life", "Back home they'd hang me, but here they gimme a fuckin medal!".
Popular anti-spam technique (Score:3, Interesting)
Re:Popular anti-spam technique (Score:5, Interesting)
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
Re:Popular anti-spam technique (Score:2, Funny)
Re:Popular anti-spam technique (Score:2)
Re:Popular anti-spam technique (Score:3, Interesting)
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)
Re:Nothing new here, move along (Score:4, Funny)
Re:Nothing new here, move along (Score:3, Funny)
There is a city nearby called Oregon City [orcity.org] which leads us to this [roadtripamerica.com] wonderful sign.
Re: Nothing new here, move along (Score:3, Informative)
> 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)
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)
Re:Nothing new (Score:3, Informative)
"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.
Re:Nothing new (Score:3, Interesting)
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
He also had a cron job on another box that checked last-access-time for the
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.
--
Re:Nothing new (Score:2)
Just like "ringers" (Score:5, Informative)
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.
Renting a mailing list? (Score:2)
I can't think of a single legitimate reason to 'rent' a mailing list.
Search? (Score:3, Interesting)
Re:Search? (Score:2)
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)
Well, yes. He is suppose to be in the Arlington National Cemetary, not a hospital.
The problem... (Score:5, Insightful)
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)
Re:The problem... (Score:2, Interesting)
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
John F. Who? (Score:2)
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...
Re:John F. Who? (Score:2)
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)
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
Re:Yes, this is old news (Score:2)
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.
Re:Yes, this is old news (Score:2)
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)
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)
Re:I do this already (Score:3, Funny)
I prefer to use a bottle of honey. You catch more people that way. I even tried vinegar, but honey works best
Re:I do this already (Score:2)
Similarly, you can label your beverage "Fluid Excretion Experiment."
Re:I do this already (Score:4, Funny)
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)
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)
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.
No, but reading the article is :) (Score:2)
"While the concept of honeytokens may not be new (think Cliff Stoll and The Cuckoo's Egg), the term is."
Re:This is new? (Score:5, Informative)
It is perfectly legal to copy all the listings out of a phone book under your own name with no attribution.
The phone book publishers that caught people copying this way discovered that it did them no good.
false alarm (Score:2)
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.
Re:false alarm (Score:2)
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
Um... (Score:2)
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.
Re:false alarm (Score:2)
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.
This ain't anything new (Score:2)
'He copied our encyclopaedia, and we know this because he has entries we made up out of whole cloth.'
Telephone book (Score:2)
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.
Re:Telephone book (Score:2)
Real Life Use . . . (Score:2)
Not as good as they sound, but useful (Score:2)
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
Been done for years - whens the patent applicatio? (Score:2)
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.
Web developers have known this trick for a while (Score:3, Interesting)
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.
really stupid idea (Score:2)
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
Exactly how would one go about monitoring data access? In theory, it's simple
Targeted mailing lists do it too. (Score:2)
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)
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.
Not new at all... dictionaries, maps, etc. (Score:2)
As far as I can tell, "honeyt
Re:Not new at all... dictionaries, maps, etc. (Score:3, Funny)
That must be where that word 'nukyuler' comes from that I keep hearing W use, right?
Keeping staff on the reservation.... (Score:2)
Old, old idea. (Score:5, Informative)
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.
Re:Old, old idea. (Score:4, Funny)
Yeah, I have this really, really, really good joke, but I can't tell you because I use it as a honeytoken.
I also have a simple proof of Fermat's Last Theorem, but it's being used as a honeytoken also. Sorry.
Wise detected pilfering info from Installshield (Score:3, Informative)
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]
Honeytoken box (Score:2)
I automatically generated reports on that basis.
I also generated reports for probes to some of the other 'nasty' ports.
possible database hack detected on slashdot (Score:2)
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.
Tom Clancy's Canary Trap (Score:2)
This is a great idea (Score:3, Interesting)
fake files on kazaa??? (Score:5, Informative)
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)
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)
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)
(Fortunately, an alternative [freedb.org] now exists.)
French railroad "standard" procedure... (Score:3, Interesting)
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)
Re:oh, you mean like my penis? (Score:3, Funny)
Re:Similar to anti-spam provisions (Score:2, Funny)
No.
Cliff Stoll did something like this when he was tracking down hackers at LBL.
The article probably wouldn't have mentioned Cliff for using this technique if he hadn't. :-)