Posted
by
Soulskill
on Wednesday May 08, 2013 @03:15PM
from the oh-bother dept.

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

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?

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.

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.

Nice to see I'm not the only one scratching my head trying to figure out WHY you would want to do this instead of...you know,actually doing it smart by using salted hashes? I mean correct me if I'm wrong but I thought the whole point was to make it so even if they got it they couldn't use it because it would take too long to decrypt, so how exactly would these "honeywords" work, unless you suspect somebody on the inside is stealing from you in which case i think you have bigger problems.

It's a mall part of defense in depth, any sensitives information that is not atomic should be stocked separated. Every speed bump you put into an attacker road is an opportunity for detection, a point for auditing.

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

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

Sorry I do enterprise identity management for a living, I might have over-though in the context of a random webapp and skip some random words here and there as I write here with a beer or a scotch after work....
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

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

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.

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.

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.

Citation please? Because the only failures i have heard of is those using already depreciated crypto like DES or SHA, have yet to hear of anybody breaking into 512bit AES, in fact last I heard that the length of time required to brute force a 512bit AES using an 8 digit password of the usual numbers, characters, and symbols and properly hashed was on the order of longer than the sun will survive, were talking tens of billions of years.

Throwing more hardware at it only gets you to a certain point, after th

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.

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.

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?

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 con

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

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

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 billin

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.

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

In that case, what you are detecting is really that the usernames are leaked and not the passwords.

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.

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

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.

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.

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

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.

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

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,

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

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

I've done something like that before. Set up some fake username and passwords (common ones like "test" and "password"), and send them to a honeypot, a reporting system, or just firewall their IP if they log in with those credentials. It keeps legitimate users unaffected (unless a hacker is specifically targeting your server and knows a valid username) and catches most of the typical script kiddies/brute force attacks.

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.

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.

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.

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.

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

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

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.

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

I think this is the scenario:
1) Honeywords (userid/password pairs) are seeded into an organization passwd file.
2) Bad guy acquire the passwd file (the "how" doesn't matter).
3) Bad guys use offline resources to decrypt the stolen passwd file.
4) Bad guys attempt to access the organization's systems/applications using the now decrypted userid/password pair aka the honeyword
5) The use of the honeyword (exact userid with the exacted seeded password) set of alert.
6) The Org can deny access and perhaps do o

They should also create fake user accounts, with fake social security numbers, fake credit card numbers etc etc. Then the thieves would waste so much of time pursuing these fake data and eventually give up not being able to tell a really dumb user with a dumb password and a fake account with a dumb password.

But it is not new. I have done something similar. But my lips are sealed about that project.

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.

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

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.

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.

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

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.

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

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.

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

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)

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.