In the wake of yet another major password security compromise that hit up to 50 million accounts at LivingSocial, a very appealing proposal published by two security researchers proposes the use of "honeywords" to enhance breach detection.
Past attacks on services like Yahoo Voices and LinkedIn have highlighted the need to strengthen the methods used to store password information on servers. As we should all know by now, anything less than salted hashes isn't good enough. But LivingSocial did use salted hashes. It will take hackers a lot of computing time to decrypt passwords from LivingSocial, but it is still possible.
Enter honeywords. As described in a research paper by Ari Juels and Ronald Rivest, honeywords would be decoy tripwire passwords linked to user accounts. Suppose that a user registers for your service and sets the password at "BlueSky72." Your system stores only a salted hash of this password in your secure database. Now suppose your system automatically generates a bunch of false passwords for this account. Imagine an algorithm that generates these false passwords from common dictionary combinations and then stores the salted hashes for them, too.
Attackers now get hold of your password hashes; perhaps they exploited some other hole and dumped your database. Your password tokens are salted and hashed, so the attackers throw your dataset at a powerful set of GPUs for brute force decoding. Thanks to your honeywords, the attackers have a new problem: They don't know which decrypted passwords are legitimate and which are decoys.
Better yet, when attackers try a decoy password against your server, a tripwire is triggered. After all, the only reason someone would use one of these decoy passwords is in an attack. At this point, your system could follow one of several paths. A silent alarm could alert administrators, potentially heading off a massive breach that makes headlines. Or the attackers could be led into a honeypot -- a protected area of the system where their actions are logged and tracked without their knowledge. This information may be useful in tracking down and/or prosecuting the perpetrators.
The honeyword strategy does raise some implementation considerations. How many honeywords should you generate for each password? The more decoy passwords there are, the larger the surface area is for your tripwire. But your database will also grow by several orders of magnitude. That could raise scale and performance issues for a service with a very large user base.
Debate has particularly grown around the question of how your system distinguishes a legitimate password from a honeyword. For example, it would be a bad idea to store a distinguishing flag in the same database as the hashes themselves. The attacker could acquire that information along with the whole database. You could create a simple database containing only flags indicating which password is genuine for each user account. In principle, this database could be stored on a separate system (perhaps even built on a different platform), reducing the likelihood of a single exploit leaking both the full database and the crucial supplemental data. But you are adding complexity to your system, and, again, there may be scale and performance issues.
An appealing alternative is to build this knowledge into your business logic. Rather than storing explicit flags for each account, you could rely on a formula to disambiguate passwords -- for example, a salt based on static information such as the username and/or registration time.
Some will argue that implementing honeywords adds a layer of complicating implementation when your effort would be better spent hardening your systems -- to secure them against database exploits and use the strongest algorithms for salted hashes. But adding layers is precisely how system security is strengthened. By using honeywords, you get a warning about an attack in its earliest stages.
And if the industry adopted honeywords on a wider scale, attackers would face a considerable amount of uncertainty over which of their stolen and decrypted passwords might set off alarms.