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."

Comments

This... is a very good idea.

[Nadaka]

It really is.

Re:This... is a very good idea.

[marcosdumay]

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:This... is a very good idea.

[djmurdoch]

It's exactly intended to detect theft of your password database. If you salt in a known way, then it's inconvenient for the attacker, but it's still possible to brute force it. And if there's a bug in whatever hashing scheme you used, it might be easy.

Wouldn't you like to know when someone has done that?

Re:This... is a very good idea.

[eddy]

You'd do it because salted passwords are falling to increasing GPU power. It's a brand new world.

Re:This... is a very good idea.

[Cormacus]

I think the point is that this method doesn't actually prevent any of the breaches that best practices (salting, using a strong hash alg, etc) protect against; rather it provides early warning that your best practices failed. If any one of your honeypot passwords get used, immediately shut everything down ala Madagascar then find and fix the hole the hackers used.

Re:This... is a very good idea.

[LordLimecat]

Salts and hashing algorithms arent supposed to be secret. The only requirement for the salt is that it be unique, and the only requirement for the hashing algo is that it be secure.

Re:This... is a very good idea.

[rickb928]

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.

Re:How does this work?

[zindorsky]

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.

This is an ok idea, definitely not a great one

[TiggertheMad]

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.......

Re:This is an ok idea, definitely not a great one

[gamanimatron]

Some responses (informed by the actual paper):

The second DB doesn't have any of the the password hashes, it just knows which one is correct. It's a single table of (userid, hashid) where hashid is just some small integer.

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.

If the second system goes down, one approach would be to just accept any of the passwords until it comes back up. Then check the logs of what happened while it was offline and act accordingly (invalidate sessions, raise alarms, whatever).

Overall, I like the idea tremendously. It seems like it's not quite all there yet, but we're probably going to start implementing some variant of it immediately.

Honeytoken

[ZouPrime]

Isn't this just a special case of a honeytoken?

http://en.wikipedia.org/wiki/Honeytoken

No it's a miners canary

[dutchwhizzman]

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?