Slashdot Mirror
Honeywords — Honeypot Passwords
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."
It really is.
This is new news? I implemented this same thing 4 years ago and it's hard to imagine nobody else has considered it.
I'm actually a bit annoyed right now: I've been working on this concept for about a month now. I guess I should be honored by the "great minds think alike" thing, but damnit, I wanted to finally get my name out there.
It's a good start and part of the technique I've been working with... great way to catch exfiltrations in progress, but we could go a bit further. Patches to critical services like SSH could be developed that would accept lists of common bruteforced passwords and automatically block and alert, or even pass the connecting client over to a honeypot.
If I make a copy of the password database and place it on my machine then how will an alarm reach the admins?
A better name?
Power Words! As in, Power Word Stun, Power Word Kill, etc.
See also http://www.d20srd.org/srd/spells/powerWordStun.htm
Seems fine so long as someone is actually interested in the passwords for the original target site. I bet a lot of hackers capture the passwords and e-mail addresses from vulnerable sites, then try them on more valuable ones. Unless sites are co-ordinating breach detection, there won't be detection in these cases.
But it is not new. I have done something similar. But my lips are sealed about that project.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
First, let me say: this is a fantastic idea. It should be in everyone's best practices for dealing with any such databases.
This reminds me of how often we see high profile targets claimed to have been successfully hacked. I remember some claim regarding hacking nuclear reactors a while ago. Often all they mean by this is they were vulnerable to known exploits. If I ran a nuclear reactor (or similar high security system), I'd put up software and hardware than was susceptible to known exploits, but controlled nothing other than a lot of write only logging (read via a different physical connection, or require a jumper). Combine tactics like that with the one mentioned here, and you both get a nice record or people trying attacks, as well as indications of real successful breaches, and the attackers may not be able to tell the difference. Thats fantastic!
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. A smarter (less invasive) approach might be to compare actual hack attempts against existing or recent lists of known usernames; if they're close, that's a tip-off that someone knows more about your authentication store than he or she should.
Too often summaries only link to spammy blogs instead of the actual sources, so good job here.
The difference is, you didn't tell anyone. http://xkcd.com/664/
A better idea would be to seed the honey pot passwords to phishing attempts while waiting for the host to close them down.
Ok, for those who didn't RTFA, or don't know anything about security, you have a list of users and encrypted passwords in a DB. They log on and their password is checked against the DB. The problem is how do you know if someone has stolen your DB so they can crack it offline? (Offline brute force attacks are much more effective since they are thousands of times faster) So the author proposes that you give each user several possible passwords in the DB, only one of which is the correct one. If other passwords are used to logon, a danger alarm goes off, and you know someone has stolen your DB.
There are several problems with this idea. To make it work, you have to have a second DB listing all the passwords, and some sort of marker indicating which ones are real and which are fakes. You can't put this in the main DB, because then the hackers would have stolen this info too, and can tell which passwords are real. So you have a second, more secure system for this. Aside from the problems in maintaining a separate parallel system, one might ask the question, "why isn't your primary DB as secure as the secondary DB?". If attackers can breach your main defenses how do you know they cannot breach your backup network? What happens if your secondary system goes down?
More insidious, there is the recursive security problem. The point of doing this is for the assurance that your password DB is secure. How will you know if an attacker has gained access to your secondary password DB? Well, that would require a third password DB.......
HA! I just wasted some of your bandwidth with a frivolous sig!
Isn't this just a special case of a honeytoken?
http://en.wikipedia.org/wiki/Honeytoken
Doesn't mean you SHOULDN'T use a good KDF like scrypt of course, but remember that these "honey accounts" can give you more information. If your data is stolen you want to know about it as soon as possible for all sorts of reasons. If someone breaks in and steals your super-safe account database, you still have a problem you want to detect and fix; the break-in itself. This can be one more layer in that protection.
Belief is the currency of delusion.
Well, it assumes that you have a "separate hardened computer system where secret information can be stored". It uses this information to allow one to know which passwords are valid.
If you have such a system, you already can store and check salted secure hashes in a good manner. So really, it assumes that a system exists that already would solve the original problem...
How to determine if an incoming account+password combo is a honeytoken is definitely the problem here.
One idea would be to add a column to the database where you store an internal hash of some account info that is available at the point of verification, where all honey accounts are hashed using one key and all normal ones using another, and then hard code this check into the application, working on the assumption that the separation between your source and the database is fairly good. It would also req. the attacker to actually look even if he also got access to the source (or reverse-engineer binaries/byte code). The column might rouse suspicion, but...
Heck, you could just add a boolean column with some innocuous name to achive the same thing I guess. Set "no_newsletter" on all fake accounts.
"I prepared Explosive Runes today."
Blessed is he who expects the worst, for he shall not be disappointed.
http://blog.jgc.org/2011/06/my-email-canary.html
The idea seems to be that the second system can be a smaller, less complicated single-function server, easier to harden and could be running a different OS/Webserver/DB stack. You could (by sacrificing real-time validation) even have the second system entirely firewalled off and unreachable to an attacker, just polling the login servers to validate the sessions at some small interval.
And how are you going to implement password resets in any sort of timely fashion on this magic one-way ultra-secure box? I can pretty much respond to any answer you will give me with either a) won't scale or b) new security vulnerability.
HA! I just wasted some of your bandwidth with a frivolous sig!
How about a monster whopping database full of salted hashed fake accounts with a tiny percentage of viable logins that notify you when they have been used.
There.
why not have fake logins? Then you don't need a separate list. If someone tries to login with the fake login, then you know there's a problem. A fake login with view-only permissions. True, they might not pick the fake logins...
But then, what if you had more fake logins than real logins? Then you'd have a better chance they'd pick the fake login.
Obviously there's some number which balances performance to security that is a sweet spot.
Why would any business want to do this? One of their canned statements after a breach is always "although security was compromised, we have no evidence that customer accounts have been accessed". Implementing such a policy means they lose the ability to spew that piece of meaningless (yet evidently popular, given it's prevelance) reassurance.
This is a good measure for high tech solutions, but why not also take it further. create new honeywords... put them on post it notes under people's keyboards etc...
I can tell you two reasons to do it. Often, the billing company manages the password list. The top billing companies including Paypal, CCBill, etc. do not use strong hashes by default. Instead, they use DES, which was secure in 1972. Hundreds of thousands of sites use a third party security package like Strongbox to provide password security for those passwords which are generated by the biller(s). Strongbox or a similar third party solution can use "honeywords" to detect breaches even if they can't control the algorithm Paypal uses.
Secondly, when SB DOES manage the passwords, it was designed to use a highly secure, yet highly portable hash. With glibc supporting crypt($1$), the best algorithm at the time was salted MD5. While still secure in THIS CONTEXT, salted MD5 could fall given the fall of MD5 in other contexts. In case salted MD5 is ever broken, this system would alert SB users if their list was compromised next year or in 2016 or whatever.
Due to the popularity of untrained programmers writing web apps in an inherently insecure language, PHP, breaches are VERY common.
From TFA:
"The researchers acknowledge that attackers might subvert their system by launching a denial-of-service attack against a honeychecker server. In such an event, they recommend using a failsafe: if a honeychecker server becomes unavailable, temporarily allow honeywords to become valid logins."
Letting everybody in seems like a weird way to failsafe;-)
Everything I write is lies, read between the lines.
You do this so you can tell that somehow your design and security measures have failed. If these accounts get used, whether it is with the proper password or just the username (or other user data in your databases) you can be sure that you have a data leak somewhere. By smart placement of the data and adding new "honey data" regularly, you should be able to predict where and when you had a breach. Don't just use user/password combinations for this concept, but also put other "honey data" that might get stolen in, so someone that steals your address database or entire customer data (internal theft by employees) will get caught. Depending on how your system is built up and used and the type of data, you can even use it to pinpoint the employee or exact server that has been compromised.
Techniques like this have been in use for many many years. Most maps have on purpose flaws in them so illegal copies are identifiable. Most address databases for sale commercially have fake addresses in them as well. I've used this sort of techniques before on large customer databases. I'm surprised that this is getting so much attention, I thought it was "industry best practice" for a while now?
I was promised a flying car. Where is my flying car?
This is one of those small ideas that are so simple and seem so obvious that upon reading them your first thought is "why didn't I think of that?".
Assorted stuff I do sometimes: Lemuria.org
Apparently I completely failed to communicate the points.
First, most often, the programmers choosing the algorithm are NOT employed by the owner of the site. The owner of the site wants to protect themselves from dumb decisions made by the billing company. Most sites use a third party biller such as Paypal, CCBill, Zombaio, etc. If you run geektutorials.com, billing through Paypal, you have no control over what algorithm Paypal uses to store your passwords*. You do, however, want to be notified when your passwords, which were hashed by Paypal, get compromised. So the person or company wanting the fix is not the person or company who made the bad programming decision.
The other scenario is when the programmers DID choose a god, secure algorithm. Ten years ago, many good programmers chose MD5 or salted MD5, which were secure at the time. Millions of passwords were hashed with MD5 and salted MD5. Later, MD5 was cracked. Suddenly, the properly hashed passwords were at risk. Strongbox or another system with this feature would alert you when the code which was understood to be secure when written is later compromised.**
* You actually CAN replace the biller's script, and we do that too. That doesn't fix the bad algorithm already used for existing users, though. So even if the biller's bad choices are fixed, an alarm is still required.
** MD5 is currently broken _for_certain_purposes_. _Salted_ MD5 _for_passwords_ is still secure today, assuming reasonable input validation. It might be broken next month, though, so an alarm is wise.
No, Marcospothead, read it again (either post). When you pay for a web site, Paypal or some other biller accepts your $5 so that you can access geektutorials.com or whatever. Paypal or CCBill or whichever biller creates your password for geektutorials.com. That has nothing whatsoever to do with your PayPal password.
BTW you may be familiar with it from when you log in to GirlsGoneWild.com or whatever. Have you ever noticed the "protected by Strongbox" message on any of the sites you visit late at night? Maybe you also noticed that yur credit card statement doesn't show the charge as being from "GirlsGoneWild.com", but from some billing company. The billing company creates and hashes your GGW.com password. The owners of GGW.com use Strongbox to watch over the passwords that are managed by Paypal or whichever billing company they use.