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."
This... is a very good idea. (Score:3, Insightful)
It really is.
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.
No it's a miners canary (Score:4, Informative)
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?
Re:This... is a very good idea. (Score:5, Insightful)
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: (Score:2)
I think you are far more likely to screw up this scheme than password hashing + salting.
The idea may be good, but more complicated and more complicated = more buggy = less secure.
Re: (Score:3)
Yes, but even if you don't screw up the hashing, brute force attacks are possible. This approach discourages those, because an attacker won't know which of the broken passwords is safe to use without being immediately detected.
Re: (Score:3)
Re: (Score:2)
TABLE PASSWORD
INTEGER user_id,
CHAR VARYING salt,
CHARACTER VARYING hash,
CHARACTER VARYING algorithm
If the attacker get your database, your still screwed.
Re: (Score:2)
It's only going to get faster generating those rainbow table, see the post on gpu somewhere lower...
The true solution is proper keys derivation and management using a dedicated security equipment, ex.: a java card with a keypad to enter the master key. Re-keying capability is a most and a cu
Re: (Score:2)
Well, that's an interesting proposal, but has weaknesses all of its own. I don't understand what you mean by using daily one time use salts with MD5 or SHA1. RC4 is a stream cipher, not a hash algorithm, and PKCS7 is cryptographic message syntax, not a padding specification. Given that a password is likely to be less than 16 characters in length, you are only going to have a single encrypted block, so I'm not sure what CBC mode gets you. So I'll ignore the cryptographic buzzword part of your proposal - ple
Re: (Score:2)
In an enterprise setting you usually have to have reversibility, to synchronized systems, as not everything is sso enabled or ldap friendly, complexity in that setting is unavoidable.
The weird part about daily salt was put into that system by decree by our clueless management that has paid a
Re: (Score:2)
Interesting, hadn't thought about synchronizing passwords across systems by having a decryptable password. I guess the other way is to synchronise them all at the point of password change. I'm currently advising an enterprise on security - hopefully not with snake oil! We have a real problem migrating from one legacy system to a new one, as resetting 100,000 passwords is kinda hard in practice.
The legacy system is already using salted hashes (top marks!), although many of the users only have 4 digit PINs (n
Re:This... is a very good idea. (Score:5, Informative)
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: (Score:1)
yup
I use SHA 512 for both the hashed password and salt, and the salt is generated by creating a very large string with multiple secure random calls.
If an attacker managed to get the hashed password and the salt AND the appropriate model file(not everything is stored in my database), it would be near impossible to crack even the simplest of passwords. At least not by the time his great great great great great great granchild is at least 100 years old.
Re: (Score:3, Insightful)
You'd do it because salted passwords are falling to increasing GPU power. It's a brand new world.
Preemptive comment (Score:2)
Doesn't mean you SHOULDN'T use a good KDF like scrypt [wikipedia.org] 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.
Re: (Score:2)
Actually good secure salting password algorithms (e.g. not plain SHA1) can't fit in to a GPU.
They chew too much memory to create one hash that a GPU can't provide but a CPU can provide easily.
Its one of their features.
Re: (Score:2)
Re:This... is a very good idea. (Score:5, Insightful)
Re: (Score:3)
This is an early warning system in case things go wrong. And things do go wrong even when competent and paying attention to best practices.
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.
Re: (Score:3)
I mean correct me if I'm wrong but
You are wrong. Good security is characterized by defense in depth. Adding another layer of defense is usually better than just trying to strengthen an existing layer. Of course you should use salted passwords. That is good practice, but there are a number of ways that it could fail.
unless you suspect somebody on the inside is stealing from you in which case i think you have bigger problems.
Really? What is a "bigger problem" than the cost of the lawsuits, lost customers, and PR disaster that would result from an insider stealing your customers' sensitive data?
Here's why Strongbox does it (Score:2)
Re: (Score:2)
So, the idea is that programmers that aren't comeptent enough to choose a good authentication library will implement that and discover they are not competent?
If you are going to change your authentication routines, why would you just put an alarm instead of making them secure?
Apparently you completely missed the point (Score:2)
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
Re: (Score:2)
But if an atacker gets your PayPal password by breaching PayPal's database, he'll use it to long into PayPal's site, not yours, and it is PayPal that must impement the fix, not you. Of course, the person that wants the fix isn't the same that wrote the flaw, the problem is that the person with the capacity of actualy creating the fix is the same person that created the flaw (and sometimes doesn't want it exposed).
Your second scenario is useful. If your code stop being updated, you get an alarm. The problem
Read it again (Score:2)
PS - that's why you see SB on GirlsGoneWild, etc. (Score:2)
Re: (Score:2)
This is like a fire alarm in a dorm. Everyone knows the buildings made out of cinder block, but you just don't know what could happen... and fire alarms are cheap so why the hell not?
Re: (Score:2)
It's probably more like a fire alarm in a concrete building that goes out every time someones fires a match or smoke a cigarrete.
Re: (Score:3)
Re: (Score:2)
You could use a difficult to guess, but plausibly looking username like for example trillyps658. Then combine that with an easy to guess password like for example password12345. The username would be stored in plaintext in the database, the password would be salted and hashed like the rest of the database, but could be one of the first t
Re: (Score:2)
That's why I'm not sure about it. The article got me thinking about how unused usernames could leak. At most sites they are simply public data, but even if not published outright this is way more likely to lead to false positives than a real security breach detection. And false positives make people lenient.
Besides, as I said, it does not detect the most likely situations where your passwords may leak.
This is an ok idea, definitely not a great one (Score:5, Insightful)
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 (Score:5, Informative)
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.
I patch the patch! (Score:2)
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.
Re: (Score:2)
In my hypothetical offline-validator scenario, it doesn't have to scale because it's not running at transaction time. Go ahead and reset the password, generate a bunch of new fake hashes and store the index of the "real" one in the same log that will be picked up for validation later on. With asymmetric encryption, the log could be stolen outright and be of no use at all to an attacker.
That said, I'd probably lean towards an online validator just so I could stick attackers in a honeypot and k
Re: (Score:1)
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?
You don't necessarily need a second DB. Just make which-one-is-the-right-one be a function of some other data, like the username.
Re: (Score:2)
Yeah, like all great ideas, it needs polishing.
I wouldn't put the real/fake distinction into the database at all. I would put it into the code. For example, a simple noise function (pseudo-random, but deterministic) using a never-changing part of the user data such as the ID as input determines which of the n passwords is the valid one.
But frankly, the fact that a single user has more then one password at all would be a dead-giveway that there's some kind of trap to any skilled attacker. If you're not inter
Re: (Score:2)
So now hackers must compromise the login tracking database as well, before deciding on which passwords to use?
First proposed this month, first used years ago. (Score:1)
This is new news? I implemented this same thing 4 years ago and it's hard to imagine nobody else has considered it.
Ron Rivest stole my idea! (Score:1)
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,
Re: (Score:2)
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 honeypo
Re: (Score:1)
I've been doing this for years via fail2ban; just doing blacklisting, not honeynet redirecting, but still...
fail2ban is great, but it has flaws. Slow crawl attacks evade it pretty easily, and real users sometimes get locked out because they forget their password and commit too many failures. This approach has none of those flaws, and gives you significantly more flexibility.
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...
Yep, that's a high interaction honeypot. Great and valuable stuff, but slightly different methodology with some different applications than this. One nifty thing with honeywords is the theoretical capability to detect actual data exfiltrations in progress.
Indeed. I've been thinking of tweaking my fail2ban jails to add a script checking for specific username login attempts. If I then seed my password file with these accounts, it should be similar to what they're doing with honeywords, with minimal effort on my part.
My setup wasn't a high interaction honeypot though; there was no actual network, just a set of canned responses for the scanners. I had a tarpit going for a while, but got bored with that, as my assets have never had enough visibility for that t
Re: (Score:2)
Re: (Score:2)
denyhosts (a program very similar to fail2ban) has explicit built-in support for that sort of thing. You can trivially configure it so that if anyone tries to log in as any of a certain list of users, that triggers the ban.
Wanna brute force my mysql user's password? Ok. I don't have a mysql user anyway, but your first attempt to be him, is also your last attempt .. to be anyone.
Re: (Score:2)
As opposed to just straight up monitoring if someone is pilfering with your shit?
C'mon now, are you suggesting this as a fix for the flawed philosophy that a user account can have any sort of privileges against a database that stores user information? There are certain methods within certain processes that might need those kinds of privileges, but the problem only arises when you equate a user and a process, and assign permissions to them from the same set.
Looking at a finer grain than [yes|no] assignment o
How does this work? (Score:2)
Re: (Score:2)
if it would be implemented that way, the attackers would steal passwd, shadow AND honeywd. Nothing gained.
It will only gain something, as long as the honeyword-response is done by a blackbox, which can start an alarm when its asked for a honeyword.
Re:How does this work? (Score:5, Informative)
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.
Re: (Score:3)
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.
Re: (Score:2)
To be clear, this isn't a Fake ID and Password. I was thrown for a moment too, since honeyaccounts are already used.
Problem #1 with a honey account is that you have to have many many many accounts to increase your odds of the attacker happening to try one of your accounts and logging in with it. Ideally you would have as many fake accounts as real ones to increase the odds of them testing a honey account early on instead of them potentially accessing dozens of accounts (which ones?) before triggering an a
Re: (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. Chan
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
The alarm will reach them when you try to use the fake passwords to access their servers.
Re: (Score:2)
If I make a copy of the password database and place it on my machine then how will an alarm reach the admins?
It won't, if all you do with the passwords is keep them on your own machine.
But if you try to use of the passwords to access the machine you took them from, that's when you risk alerting the admins.
Re: (Score:2)
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, an
Re: (Score:1)
Honeywords? No... (Score:2)
A better name?
Power Words! As in, Power Word Stun, Power Word Kill, etc.
See also http://www.d20srd.org/srd/spells/powerWordStun.htm [d20srd.org]
Re: (Score:2)
"I prepared Explosive Runes today."
Why stop there? (Score:1)
But it is not new. I have done something similar. But my lips are sealed about that project.
A problem with this is... (Score:3)
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.
Re: (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 de
Re: (Score:2)
>> username/password combinations don't have to be the same
If you've implemented SSO on even groups of systems, they will be the same. :)
>> 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
To do that, you need to set a "fake" flag on the credentials, and bad guys can use that to filter out the fake creds from the store.
>> these act to dissuade attackers in the same way as "sting operations" ac
Re: (Score:3)
To do that, you need to set a "fake" flag on the credentials, and bad guys can use that to filter out the fake creds from the store.
Clearly the "fake cred" would never be a flag in the users table (or even in the same database/system). For example, it could be a process that scans your logfiles and alerts based on username.
If someone has pwnd your system and can rewrite logs you have a *much* bigger problem than stolen passwords.
Re: (Score:2)
>> Clearly the "fake cred" would never be a flag in the users table (or even in the same database/system). For example, it could be a process that scans your logfiles and alerts based on username.
That's my point. If you're already doing this, you don't need to inject fake credentials into your databases to detect unusually accurate snooping.
Re: (Score:3)
>> Clearly the "fake cred" would never be a flag in the users table (or even in the same database/system). For example, it could be a process that scans your logfiles and alerts based on username.
That's my point. If you're already doing this, you don't need to inject fake credentials into your databases to detect unusually accurate snooping.
We're not on the same page.
How would you know if a login using a valid credential set is legitmate or from a stolen password? Answer: you don't. However, if you have fake users in your system that *no one* would ever login with, then you can know your system credentials have been compromised.
And this is to detect if your password db has been stolen, not "snooping". Using this method to uncover snooping would never find your fake credentials unless you constantly test those fakes.
Re: (Score:2)
The "fake" flag, as you put it can be stored on a separate server and since it is storing such a small, tiny fraction of your user data (a map of usernames to an integer indicating the correct hash to look for) it can be much more tightly restricted.
Re: (Score:2)
The whole purpose of this system is to detect "actual hack attempts". No one is going to brute force a good password directly on the service, they're going to get a leaked/stolen copy of the password database and try to crack the passwords locally. With this system, the attacker doesn't know which hash is the one that will actually grant access. You could have 100 hashes for each user; enter the correct password and access is granted, enter a random password and access is denied, enter a password that ge
Re: (Score:2)
Phishing (Score:2)
A better idea would be to seed the honey pot passwords to phishing attempts while waiting for the host to close them down.
Honeytoken (Score:5, Interesting)
Isn't this just a special case of a honeytoken?
http://en.wikipedia.org/wiki/Honeytoken
Similar to an Email Canary (Score:1)
Re: (Score:2)
Ugh. I hate that idea. It's based on presumption that people have HTML email reading turned on. I wouldn't trigger your canary while snooping through your emails, not because I'm clever or anything, but just because I wouldn't think to turn HTML on. Worse, if I did think to turn on HTML email, I would also have to enable external images, yet another non-default in most IMAP clients.
I'll Raise You.. (Score:2)
There.
Re: (Score:2)
Well, the paper does acknowledge that approach:
"Sometimes administrators set up fake user accounts (\honeypot accounts"), so that an alarm can be raised when an adversary who has solved for a password for such an account by inverting a hash from a stolen password le then attempts to login. Since there is really no such legitimate user, the adversary's attempt is reliably detected when this occurs."
The only reason why this approach may not work according to the paper is:
"However, the adversary may be
uhh (Score:1)
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.
For added security (Score:2)
Strange failsafe (Score:2)
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;-)
Re: (Score:2)
Well no, it doesn't let everyone in. If you have chosen your honey words carefully, they should be about as secure as the original password was. It would just mean that more than one password could theoretically be used to log in with, and you couldn't use them to detect a breach of your password database for that time. This clearly weakens security a bit, but not by much, and maintains availability of the service (presumably temporarily)
Re: (Score:2)
Sorry replying to myself - I didn't think that through very clearly - you are right.
There are only two reasons to mount a denial of service attack against the honey word server. One is pure denial of service to prevent anyone logging in. The other would be if they had already offline compromised the password database and wanted to exploit it.
I guess you could take a specific DOS on your honey word server as an indication that your password database may have been compromised.
Re: (Score:2)
Yep, I do not want to troll/bash but just reading that paragraph in TFA made me doubt about the seriousness of those researchers.
Could be a mistake in TFA or a researcher wrongly cited I don't know...
brilliant (Score:2)
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?".