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.
When you use one of the fake ID and passwords to try to log in. That will set off an alarm in the system that someone has stolen the database. Think about it - it's really quite clever.
If the geiger counter does not click, the coffee, she is not thick.
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.
An adversary who steals a file of hashed pass-words and inverts the hash function cannot tell if he has found the password or a honeyword.
Nevermind it was in the second link. Basically the attacker gets a 1 in 3 chance on each login of tripping alarm when logging in. Stronger passwords would stand out from the honeywords though if the honeywords are weak passwords. If honeywords are strong passwords then weak passwords would stand out.
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.
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.
I've been doing this for years via fail2ban; just doing blacklisting, not honeynet redirecting, but still...
One thing I used to have set up was a redirect to a secondary firewall table for hosts entering the wrong passwords; the secondary firewall table had redirects to a dummy server that was configured with a completely fake network and service topography... so if someone started attacking using an IP, the information they gleaned would be completely misleading without actually providing an active honeypot. Dummy server has since been repurposed and now I just block though; don't have the time to waste examining what people/bots are up to these days.
If I make a copy of the password database and place it on my machine then how will an alarm reach the admins?
I'll answer the "How does this work?" part, as your comment has nothing to do with the information provided.
If you have a copy of the password db, good for you. If you crack the accounts and try to use an elevated account to access something, and that elevated account is a dummy account, alarm bells will go off everywhere. That's how this works. And everyone should be doing it.
Back in the day, I did something "similar" where I created a bunch of "default" accounts using common usernames and passwords, and gave those accounts no access. Syslog was set to send an alert and blacklist the incoming IP for 3 hours. In the 3 years I had this running, I only caught a handful of attackers, but hey... that shows that they would have got through had those accounts actually been in use.
Now I just use fail2ban.
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
When you use one of the fake ID and passwords to try to log in. That will set off an alarm in the system that someone has stolen the database. Think about it - it's really quite clever.
Isn't this kind of like ISP-based spam detection - when you create a list of honeypot email addresses that no one would ever email on purpose - anyone who sends to those email addresses are likely a spammer, and should be added to the spam sender blacklist.
Make sure everyone's vote counts: Verified Voting
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.
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?