Comments
This technique is already used in big customer database.
Inserting fake customer with address pointing to lawyer is an easy and cheap way to know if the database has leaked.
Mark Currie • May 6, 2013 7:16 AM
Why don’t they perform multiple hash iterations on the passwords (with salt)? This idea has been around for some time now. Most servers don’t get enough traffic to make this an onerous task and those that do can afford to invest in GPU accelerators.
Smee Jenkins • May 6, 2013 7:34 AM
I think @Mark Currie has it.
If you’re sophisticated enough to do this, you’re sophisticated enough to protect your passwords properly in the first place, so these “honeywords” shouldn’t be necessary.
999999999 • May 6, 2013 8:07 AM
What about having many decoding schemes that yield many possible solutions but only one of them is correct.
Lets consider a book cipher:
1) take a known literary work
2) use a simple number cipher (like 12345)
3) take the first word (or letter) skip two and take the next word, skip three and take the next word and so on…
4) It is possible to have many number combinations that are valid phrases but only one of them will be the correct one
In this way you have many honeywords. Like hiding one book in a library without labels
Daniel Hagan • May 6, 2013 8:07 AM
@Smee Jenkins,
Those are really two different issues. Using strong (high iteration & salted) password storage aims at making password disclosure harder. Honeywords aims at detecting when password disclosure has occurred. They are complementary approaches for defense in depth, not an either/or decision.
derp • May 6, 2013 8:18 AM
I believe they did this at defcon along with the “trolling with math” lecture where a guy boobytrapped binaries so if somebody tried to reverse engineer them they would takeover the browser or shut down their VM/pc
bcs • May 6, 2013 8:42 AM
As for “just use salt” that only works if you can change your infrastructure or did it from the get go. This works regardless.
Also if you do salt, including many fake accounts with random hashes will work also and not run afoul of the does this look like a real PW.
OTOH if someone steals your PW DB how do you stop them from stealing the list of trap accounts?
Matthew Pounsett • May 6, 2013 9:11 AM
The scheme seems to assume that an operator is just leaving a bare file full of passwords on the system somewhere, unrelated to a list of users, and that attackers will be trying to match successfully decrypted passwords to user accounts. This seems like an assumption of either an incredibly badly designed authentication mechanism, or a sloppy operator that leaves lists of valid passwords laying around.
When I first read the blog post my assumption was that it was talking about honey accounts, which would seem much more useful.
Andy • May 6, 2013 11:31 AM
I know that this must be a bad idea but:
Why not keep the passwords inside the OS and not make the password file readable by everyone??
Nick P • May 6, 2013 12:25 PM
Knowing people are trying to crack a password file tells you… your password files are very unprotected and you have enemies looking for ways in. The former shouldn’t be true at all, while the latter is always true. So, you get the alarm and what’s next? Your intrusion analyst starts combing through logs, tries to identify source of attack, looks for unjustified service usage patterns, etc? Wait, this is exactly what defenders without the honeywords scheme must do!
I think it’s better to invest in account or service level monitoring. Identify who can do what, build profiles during a few months of ordinary use to act as a baseline, and then investigate alarms set off by people violating the baseline. Also, invest in good preventative measures for common attacks and good design on things like authentication systems.
If your enemies can still just snatch your password file to own your assets, You’re Doing It Wrong.
a different phil • May 6, 2013 12:45 PM
Even if you have taken what you consider to be your best efforts at security, it’s still nice to have a way of being alerted that your best efforts have been subverted. Belts and suspenders…
encrypt everything • May 6, 2013 1:38 PM
Or you can properly escape sql, or use ORM like django does to avoid having your db yoinked. Can also grep the logs to see any possible db attacks and know its been stolen long before they are able to decrypt it.
Adam • May 6, 2013 2:16 PM
Kind of obvious really. I also expect credit card companies, banks and the likes of Amazon, Ebay etc. “seed” phishing sites with bogus but seemingly legitimate personal details which signal someone attempting an attack. Imagine all the fun one could have logging that info, planting evercookies on the host machine and so forth.
And if they don’t do it, they should.
Brandioch Conner • May 6, 2013 2:42 PM
I think that Nick P has the essentials correct on this. There are very few scenarios where a cracker would be able to get your password file WITHOUT also being able to collect the usernames/passwords that are currently in use.
About the only one I can think of is someone in IT in your company takes the password file home or something.
But if that is what you’re trying to detect then you have bigger security issues.
Clive Robinson • May 6, 2013 7:52 PM
Not being funny but “what’s new here?”
Lets go back a century or so, and in the process equate the username with an address and the password with the door key.
Back then they had locks that would take a number of different keys (passwords) some of which would trip a silent alarm. These keys became known as “duress keys”
Fast forward over the first world war and into the second the idea of “duress keys” was taken forward into “duress indicators” whereby a wireless operator could indicate to their controler that they had been captured and were sending messages under duress.
Now skip forward into the 1980’s and various agencies were suffering security leaks of one form or another that proved extreamly embarising. Somebody came up with the idea of “Canary traps” where by documents that were printed out had had minor changes in formating etc that indicated who had printed out the document and when. In essence it was an early form of watermarking that would give away the leak to the press etc.
And of course we now have digital watermarking in pre-release review copies of films, television programs and music etc and I suspect in some cases other media such as preprint review books.
All of these systems can be seen to be precursors of this idea in one way or another along with the old faux telephone numbers and addresses etc in telephone directories and maps as others have mentioned above.
And if you look back on this blog you will find I’ve suggested using “duress passwords” in discussions with Nick P and others for systems to hide critical information from the likes of the DHS when being “required to log in” in when crossing borders etc.
So no the basic idea is not new it’s just a slight variation on whats been done or discussed many times befor.
Wael • May 6, 2013 9:01 PM
@ Clive Robinson,
Lets go back a century or so…
I see your century, and raise you 40 more centuries. Let’s go back to Ancient Egypt with its secret passages, “honey pots”, and booby traps…
Gweihir • May 6, 2013 10:23 PM
@Clive Robinson: There is nothing new in the idea, but it is important to bring it up from time to time.
Example: A while ago I did a presentation on properly protecting passwords by iterated hashing and salting to a bunch of IT security people and some had never heard of it and most were fuzzy on the actual details and trade-offs involved. On a different occasion (earlier), I had to explain to a security architect why a single hash is insecure with 6 digit passwords, in particular if the attacker model is your DB administrator that can get at all hashes with little effort.
Bottom line is that things have gotten so complicated in IT security that people have trouble recognizing the classics in that sea of detail and often miss them. Hence bringing them up from time to time is a very good idea and if it is with a neat new(-ish) application, all the better.
Gweihir • May 6, 2013 10:28 PM
@Brandioch Conner: I don’t agree. In modern enterprise architectures, DB backend and application frontend are separate. To get the passwords, you need to attack the frontend. To get the hashes, you can attack the DB, get access to a backup, or, if incompetently done, even a testing environment with life data. Front- and backend are run by different people and departments and often they do not even talk to each other or know who the others are.
Also consider that stealing the password hashes requires one copy operation, while stealing the passwords at the frontend requires prolonged listening after the system compromise and careful exfiltration of the data gotten. A huge risk of discovery (making the data pretty worthless) comes with that.
Brandioch Conner • May 7, 2013 2:06 AM
@Gweihir
Whether the attacker:
a. gets root access on the front-end and installs a password logger
or
b. gets root access on the back-end and copies the password file
The attacker still needs root access on a server in one of those segments.
You’ve been cracked and you didn’t even know it. And you don’t know to what extent or for how long. The security systems completely failed or were ignored. That’s the bigger problem.
neill • May 7, 2013 2:34 AM
you need 2 real passwords and lots of fakes
- one to give you access
- one to give you limited access (waterboarding etc)
- the others to destroy the files, with CBC you need to change only a few bytes
Mark Currie • May 7, 2013 2:56 AM
@Brandioch Conner
In Gweihir’s defence it is possible for a server’s password hashes to be captured through a simple SQL injection attack. In this case you are not gaining root access.
Nir • May 7, 2013 4:19 AM
Quote from the paper: “The honeychecker is thus a separate hardened computer system where such secret information can be stored”
So, if we have a separate computer that can securely store login information and we have to contact it every login to check if the password is real or honeyword – why not store the password hash database there and get it over with?
Why do I need a copy of the password hashs on a vulnerable system at all if I have a secure system?
Christian Loch • May 7, 2013 7:03 AM
In my opinion, the idea is not that simple: It requires a “separate hardened computer system” which is not trivial to run. Especially, the credentials to access the second system must differ from those for the orginal system. Also, the scheme cannot be simply set up on top of existing user/pass authentication systems without changing them significantly.
Furthermore: What happens when the honeychecker is unavailable? Would everyone be locked out from the application or should the system then accept honey passwords too?
bob • May 7, 2013 9:28 AM
People seem to be missing the point:
Honey word – Every account has many passwords associated with it. Only one is “real”. If a honey password is used, it must be via an attacker.
Contrast with…
Honey account – An account that looks valid but the details are only known to the admin. If the account is accessed, it must be via an attacker.
This is completely separate to salting, peppering, encrypting and all other best practices.
Nick P • May 7, 2013 11:21 AM
@ bob
“Honey word – Every account has many passwords associated with it. Only one is “real”. If a honey password is used, it must be via an attacker.”
Oh we understand it. We just know how most attackers compromise passwords on remote systems and brute force online attacks are rarely it. Plus…
“So, if we have a separate computer that can securely store login information and we have to contact it every login to check if the password is real or honeyword – why not store the password hash database there and get it over with?” (nil)
…having a separate hardened system for security purposes allows us plenty more options that have more value. I’ve posted some in the past. In this case, it adds extra cost and single point of failure to the honeywords scheme that might not be justified.
Brandioch Conner • May 7, 2013 11:52 AM
@Mark Currie
I understand what you’re saying. But SQL injection is a coding error that was identified over a decade ago.
And security scanners can detect it.
So if the attacker is collecting the password hashes via “low hanging fruit” such as SQL injection then you have far bigger problems.
poison • May 8, 2013 5:21 AM
Isn’t this idea rather silly?
1.) If someone breaks salted, key-stretched sha512, the world has a bigger problem. Or should I use md5 for the fake passwords?
2.) What makes the second system more secure than the first one? If the first system is compromised shouldn’t I assume the second one compromised too (The first one has to have access…)?
3.) Wouldn’t it be more effective to create ‘honeyusers’? The username is usually available in plaintext. If my database is compromised/published I can google it plus attackers don’t have to break the hash first to try and use the login and be detected.
Me • May 8, 2013 10:29 AM
@poison
Actually, I heard that the entire sha family of hashes is too fast for secure password storage. That is that it doesn’t have to be ‘broken’ to allow people to create data from a hash, the brute force method is actually fast enough of on some hardware.
I’m pretty shocked that people are saying this is no good because it’s only useful if you get your password file stolen and people start cracking passwords in it. Particularly given the quality of the comments usually posted on Bruce’s blog. Using bcrypt or something similar is great. Keeping your servers as secure as you can is great. That doesn’t mean things you run can’t be cracked. Wouldn’t you rather know if your thought-to-be-bulletproof system had holes? Maybe some customer support rep with too much privilege thought logins took too long and turned down the cost in bcrypt. Want to find out when users complain that their credit cards are being charged without their consent or when someone tries to log in and uses the wrong key?
Yes, it requires extra infrastructure that has to be “hardened”, which is certainly a legitimate criticism of the method, but that server only has to do a relatively simple thing. But the argument that you shouldn’t have any security holes and therefore don’t need a tool to detect breaches is absurd.
Nick P • May 8, 2013 9:42 PM
@ Nathan
“I’m pretty shocked that people are saying this is no good because it’s only useful if you get your password file stolen and people start cracking passwords in it. Particularly given the quality of the comments usually posted on Bruce’s blog. Using bcrypt or something similar is great.”
They claim to help for bad user password habits and password theft mainly. The thing about password theft is it usually happens by malware intercepting a correct password (huge amount there) or theft of password database. Just knowing that greatly limits how useful this tool will be. For remote web connections, we already need to look at other tools.
So, what about online password guessing or password database theft? It can definitely help. Know what it really is though? Obfuscation. Obscurity. These aren’t dirty words to me: I’m a fan of adding tricky layers to throw off attackers. I might even use this one sometime. Want to know another obfuscation technique that stops this threat and tons of others? Use a non-standard (insert processor/OS/stack here) and hide that you’re using it. Many are super cheap and easy to configure too.
So, the technique might do what they say it does. The paper notes possibilities where it might fail if enemies start looking into it. Further research is needed. Meanwhile, we have a huge swath of well-understood tactics, techniques, products and academic contributions to use to combat this and other issues. I’m just more excited about them, as I’ve been using some successfully for years and others may stop more types of attacks.
Yet, as I said, this is might end up in my toolbox in the near future as we learn more about how it fares in practice. Aside from alternatives maybe being a better option, I’m also concerned about single point of failure. I would also, as I usually do, look into possible expansions of this idea and the device running it before I try to field it. Might be a better security ROI variant waiting to be thought up.
(Note: In case the last point sounds vague, here’s an example. A mail guard. You have two sides processing mail and one or more trusted middle functions that check/move it. A more useful variant on this might be a “message guard” with plugins for specific types of messages. Email would be one of them. It could handle other stuff in the future without a total replacement or redesign. Might be a similar enhancement for the honeywords scheme, too. )
Clwydshire • May 10, 2013 2:59 PM
I’d like to suggested a related scheme. Give a limited number of credit-card holders a “scam-breaker” credit card number, so that when “Rachel–in card services” calls and tries to scam anyone gullible who answers out of their credit card number, the card-holder can use the scam-breaker number. A business that accumulates scam numbers gets charged twice the amount it tries to put on the card. Shoot “Rachel–in card services” and all her children. Thanks for the opportunity to blow off steam.
BW • May 23, 2013 4:54 PM
I’ve thought about a similar idea, which came up in the context of the Scripps-telcoms fiasco (still unfolding).
You setup your firewall to look at requests and if a googlebot successfully accesses your restricted files, it sends up a flare and cuts off all access. Sure you could just use the robots file to fend off search engines but that doesn’t discourage an attacker who might spider your site ignoring the robots file.
Of course you could just do a real security audit.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Per Thorsheim • May 6, 2013 6:08 AM
This paper caused immediate discussions on Twitter & mail as soon as the “password cracker” universe became aware of it.
Discussions include topics such as:
Possibility of alarm DoS by deliberately using false passwords trying to login to many accounts.
Strength/weakness of “honeyword” generator to generate “realistic” passwords for hashing, in order to blend in with the typical passwords of a specific user, and/or general users given a certain type of site/services offered. If the real password & honeywords gets cracked, and the real password stands out from the remaining ‘honeywords’, spotting the real password might be easy.
At the expense of increasing your pwd DB by 20 times (as default suggested in the paper), additional hardware, ‘secure’ hardware, backups, power and more, you might end up with a solution that is no better than before you implemented honeywords.
(Thx to Marsh Ray, Matthew Green, Matt Weir and others for good discusssions on this!)