This paper proposes the concept of honeywords for detecting if a password database has been compromised.

As far as I understand it works like this:

You save n password hashes for each user, one that actually contains the real password and n-1 that contain so called honeywords (false passwords). The correct password hash is stored at a random index between those honeyword hashes.

If now one of these honeywords is used in a login attempt instead of the real password, the server can ban the account, trigger a silent alert or redirect the attacker to a honeypot of some sort. Either way the server will know that the password database has been compromised.

To check if the password is real, the server determines the index of the given password hash and contacts another "secure" server which confirms if this is the correct index for this user (or a honeyword index).

Does this method really add any real life security benefit?

This is the attack scenario from the paper, where honeywords are supposed to help:

Stolen files of password hashes: An adversary is somehow able to steal the files of password hashes, and solve for many passwords using offline brute-force computation. He may more generally be able to steal the password hash files on many systems, or on one system at various times.

In this scenario the attacker obviously already has gained access to the system.

  • Would he really need the password data then anyway?
  • If he has was able to access the password store, wouldn't he be likely able to access the "secure" index store as well, which identifies the real passwords? Just distributing the authentication over two servers doesn't seem much more secure to me.
  • If the compromised system can find out which is the right index, surely the attacker can as well.

Maybe I am missing something in the concept, but wouldn't it be more useful to make sure the passwords are securely hashed and the first layer of security keeps the attacker out in the first place?

Are honeywords worth considering to put them into a real life web application?

4 Answers 4


You're reading the proposal slightly wrong. This is not intended as a safeguard to detect an intrusion to already compromised system, but as means of detecting compromised system's database. This is a whole different scenario, where the attacker wouldn't already have gained access to the system by knowing any end user password, but somehow (improperly discarded backup, physical break-in,...) got his hands on a leaked user database that stores hashed passwords.

The assumption is, that the attacker wouldn't know which brute-forced hash matches the true password of an individual user, and might trigger the alarm by using the honeyword password instead. It's quite a sane method as much as I read about it so far, but have yet to see any real-life implementations (the computational overhead is substantial on proper hashing using slow algorithms). It's also slightly questionable because of the limited abilities of the honeypot itself to prevent additional login attempts by other IPs the attacker might use once the previous IP used was already blacklisted (this is trivial to do to a would-be attacker), but the detection mechanism is sound nonetheless.

Question is, what should happen next, after such attempt is detected. The most obvious solution is to disable the user account in question (the one that the attacker tried to hack into), but what happens when a true user himself enters one of such honeywords by mistake? These words should be substantially different to what user himself chose as a password, and there are other constraints such as where in the database to position the real password in relation to honeyword ones?

Still, these questions might be trivial to address properly, and cheap in comparison to what would happen without such safeguards in place. This said, the answer to your question is - yes, definitely.

  • 1
    To add a note to this good explanation: Honeywords are analogous to a physical system being tamper evident, as opposed to tamper resistant. They add security by reducing the time to detection of a compromise. Commented May 7, 2013 at 19:14
  • @BrandonFranklin - Yes, good point but I assumed that's already known to OP. I also forgot to mention why that part on substantially different honeywords to real passwords can be problematic. The problem is, they need to be computationally faster to brute-force (lower hanging fruit), but not simply shorter versions of real passwords either, for obvious reasons (user typos e.t.c.). This creates another paradigm - would finding out the algorithm used to create these shorter bogus passwords expose the real ones? It's avoidable, but shouldn't be just brushed aside, as if completely irrelevant.
    – TildalWave
    Commented May 7, 2013 at 19:24
  • I'd think you could use a honeyword from common hacking wordlists to be sure that the hacker will find it before they find the user's real password. Since there are millions of words in a password wordlist and you pick only a few of them for the user's honeywords, there's a slim chance that the user will stumble across the same words you picked, and if they do, worst case is you lock his account and he has to unlock it. And you should probably prevent a user from using a password from a hacker wordlist in the first place.
    – Johnny
    Commented May 7, 2013 at 21:42
  • 1
    Okay, so this is mainly a detection method for a physical theft instead of a virtual. Only the DB is compromised, not the system. Thanks for clearing that up.
    – magnattic
    Commented May 8, 2013 at 13:17

The main thing I see that makes this not work is that a smart attacker is rapidly going to figure out what it is if they get the DB dump and then know they have to get the valid hash selection from another server. It does add another level of difficulty, but I wouldn't expect a hacker to trigger this since it's pretty obvious what is going on if you have 50 password hashes for 1 user.

It is effectively the same as having all the passwords stored without a link to the user in your main DB and having a second server tell the server which password hash should be used each time, though there is perhaps a higher likelihood of false positives in that case as people may use similar passwords and thus accidentally use someone else's password. Looking for multiple incorrect password attempts to match with different users would be a good way to rapidly figure out that someone was trying to match them up though and would be slightly harder for the attacker to know what was happening. (Though they would still see that your main DB doesn't link usernames to PWs and would look for that information.)

  • the paper says the trap-passwords should be easier to crack than the real one. Then:
    • it also means that if a cracker can get trap-passwords it by no means says the real password is at any risk;
    • If I put a password of 'qwe123' 'complexity' , there is no need in any new method to predict that such password will be cracked soon, given the login process is available to the attacker.

This method seems to emphasize 'security through obscurity' model - it makes sure your passwords are safe as long as no one is trying to crack them. Also take into account the resources needed to implement such schema (Anyone asking Bill to change Windows security model?) and it makes this paper an interesting thought/academic exercise rather than anything practical,IMO. And by the way this idea compromises fundamental practice of the honey-anything - you do not make your production more vulnerable for any purpose.
The network honeynets are good in that they can be isolated from production completely, so even if the real compromise happens, no damage is done. Here, what if the attacker compromises such honey-password sooner than it can be noticed? And what if this honey-password due to human mistake when setting up gives real user-level access?

  • "...this idea compromises fundamental practice of the honey-anything - you do not make your production more vulnerable for any purpose." I fail to see your point here. It's not making anything of value less safe, it's creating a bogus target - that's the whole point of honeypots! Why would you assume that the trap, once triggered, wouldn't be able to react to new attempts in real time?
    – TildalWave
    Commented May 7, 2013 at 18:57
  • Authors speak of adding bogus/trap passwords to existing, and thus production systems. They do not say - create a new bogus system for this. So, the cracking attempts against such passwords will be against production system. In usual sense of the honeynet word - it would equal to installing honeypot on existing/production server, you just don't do such things .
    – Yuri
    Commented May 7, 2013 at 19:59
  • Cracking attempts will be on off-line leaked user database, not on a live system (those should be detected by other means, we're not talking of trying all possible passwords on a production server here, if that's permissible then what's the point in trying to protect an offline copy from being misused by brute-forcing its hashed values?). The point being, you'd have a greater chance in detecting this database was compromised and decide accordingly what to do next, while not having any such mechanism in place might allow a successful attacker to slip by completely undetected. You pick.
    – TildalWave
    Commented May 7, 2013 at 20:08
  • Great :), so suppose only off-line DB contains such trap passwords. The cracker works hard and finds one, then he would try it against live system. So the live system has to accept such password and check with some DB if it is a fake pass or real , right? So the live system still has to have access to fake pass DB and work with it, and we (IMO) are back to square one. Your point about detection is valid, only that my concern here is that the gain is not worth the risk/pain.
    – Yuri
    Commented May 7, 2013 at 20:17
  • The gain is not worth as much with the way the linked paper proposes this honeyword checker implementation (section 2.3). It's completely wrong in that part, and @AJHenderson correctly describes why and where in his answer. It still adds a certain value to it, albeit a lot smaller than it could've. But the use of honeywords isn't a completely useless idea, if implemented without the need for an additional honeyword checker system. It's possible to add a tag into an encrypted password salt (peppering) and then compute user credentials on all stored values. It's however compute expensive.
    – TildalWave
    Commented May 7, 2013 at 20:33

Yes it does bring some security value.

This is a security measure that could be likened to CCTV, it is a detective control, and may allow you to take steps before things get to out of hand. Disable accounts / Reset users account passwords / notify users promptly incase they reused passwords.

Would he really need the password data then anyway?

Not for this system necessarily, but he will likely try this email/password combination on other sites for password reuse.

  • But the honeywords will not "work" on other systems, they will simply be rejected. In the best case this would slow down an attacker on another site.
    – magnattic
    Commented May 8, 2013 at 13:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .