Honeywords — Honeypot Passwords 110
CowboyRobot writes "Businesses should seed their password databases with fake passwords and then monitor all login attempts for use of those credentials to detect if hackers have stolen stored user information. That's the thinking behind the 'honeywords' concept first proposed this month in 'Honeywords: Making Password-Cracking Detectable (PDF),' a paper written by Ari Juels, chief scientist at security firm RSA, and MIT professor Ronald L. Rivest (the 'R' in 'RSA'). Honeywords aren't meant to serve as a replacement for good password security practices. But as numerous breaches continue to demonstrate, regardless of the security that businesses have put in place, they often fail to detect when users' passwords have been compromised."
Re:How does this work? (Score:2, Interesting)
There are a couple of ways:
1) You attempt to log in to a service using the honeyword. This trips routines in the code that recognize the account as a honeypot account and not something real, which throws alerts. This seems to be the method being suggested in the paper, though I've only glanced at it so far.
2) A better way that I don't see mentioned: using an IDS. Set up custom rules at host and network layers to look for the occurrence of a given set of 'honeyword' strings and their encrypted variants. Chances are when an IDS throws a flag on this rule, its because your auth database is being exfiltrated over a plaintext protocol (which will often be the case with SQL injection type attacks). If you're unrolling SSL or using something like mod_security to do the scanning, you can catch even the exfiltrations that are using HTTPS.
Re:This... is a very good idea. (Score:5, Interesting)
It's an interesting and intriguing idea, yeah. But I still didn't settle on "good".
How is an attacker supposed to get such passwords? He certainly can't phish them or get them in transit or while in memory. We are protecting against the password database leaking, but then, it's a set of salted hashes, so it's useless for the attacker... Unless it's something so easy to crack that you can be sure that it'll get cracked, but then, you are probably receiving several login attempts with those passwords already.
Re:A problem with this is... (Score:2, Interesting)
When you "seed your authentication databases with fake passwords", you've really just added a bunch of accounts with the same username/password across multiple systems.
Not necessarily. The username/password combinations don't have to be the same, and they can be trapped higher up the chain in the code that processes authentication requests so that they can't actually be used to gain access to systems. Better yet, they can be used to redirect attackers to higher interaction honeypots where their nefarious deeds can be monitored. Imagine your SSH daemon integrated with honeywords for the root account and other common ones, that redirect attackers to a heavily sandboxed kippo session. Now you're able to get a lot more intelligence about the attacker's methods.
A side benefit: these act to dissuade attackers in the same way as "sting operations" act to dissuade Johns and car thieves... attackers have to think twice when they run across what seem to be juicy targets. Combined with sophisticated deception techniques, you could end up feeding your competitor industrial espionage "secrets" that only served to delay and misdirect, "punishing" them for trying to steal your secrets.
Honeytoken (Score:5, Interesting)
Isn't this just a special case of a honeytoken?
http://en.wikipedia.org/wiki/Honeytoken
Re:This... is a very good idea. (Score:5, Interesting)
I've done this for more than a decade. I first heard about this in database development, seeding the subscription table, for instance, with fake subscribers to both test that delivery was made ( I and my address was one of the fakes) and to catch thieves using the list. Virtually every mailing list I've handled has had trap users in it. Every mail server I've built has had traps in it both to verify spam and catch the thieves.
This is virtually BAU for me and my fellow admins on servers that we maintain. Trap users and such are very handy. I usually have a few users with no shell or anything on the server(s) just to catch this, and log analyzers that watch and report.
And I expect we'll get pwned again some day. It used to be script kiddies pretending to be ninjas haxrs, but nowadays it's mostly random attackers that hate me, or generic botnet and compromisers by the tens of thousands. Sometimes I would rather not run a mail server.
Fortunately, the last few times we've had trouble, I was able to trace back close to the offenders. The university network guys were marginally interested, but the ISP in the southeastern US took action. I don't expect them to do that again, so I just watch and wait.
But trap users, seeding honeywords, very good ideas.