Amid a barrage of password breaches, “honeywords” to the rescue

Decoy passwords would trigger alarms that account credentials are compromised.

Security experts have proposed a simple way for websites to better secure highly sensitive databases used to store user passwords: the creation of false "honeyword" passcodes that when entered would trigger alarms that account hijacking attacks are underway.

The suggestion builds on the already established practice of creating dummy accounts known as honeypot accounts. It comes as dozens of high-profile sites watched user data become jeopardized—including LivingSocial, dating site Zoosk, Evernote, Twitter, LinkedIn, and eHarmony to name just a few from the past year. Because these dummy accounts don't belong to legitimate users of the service and are normally never accessed, they can be used to send a warning to site administrators when attackers are able to log in to them. The new, complementary honeyword measure—proposed in a research paper titled "Honeywords: Making Password-Cracking Detectable—was devised by RSA Labs researcher Ari Juels and MIT cryptography professor Ronald Rivest, the latter who is the "R" in the RSA cryptography scheme.

The new measure calls for a file storing cryptographically hashed passwords to contain multiple passwords for each account, only one of which is valid. Attackers who manage to crack the hashes would have no way of knowing if the corresponding plain-text password is real for a particular user. Logging into an account using one of the decoy passwords would immediately cause a "honeychecker"—located on a separate, hardened computer system—to issue an alert to administrators that the database has been compromised.

"This approach is not terribly deep, but it should be quite effective, as it puts the adversary at risk of being detected with every attempted login using a password obtained by" cracking, the researchers wrote. "Thus, honeywords can provide a very useful layer of defense."

Sites that used the system might store 20 hashed passwords for each user—only one that actually logs the user into the account. The hardened monitoring server would check if each password was the real one or one of the honeywords. Login attempts that used any of the fake 19 honeywords would immediately be reported. Admins could program the system to respond to the honeywords in a variety of ways, including suspending the particular account pending a security reset or letting the login proceed but on a "honeypot system," which is a trap designed to monitor the breach and prevent attackers from accessing a real account.

"The trick is to make the remaining 19 passwords look as good as the actual password, so the attacker is as likely to crack one of them as she is to crack the real password," Matt Green, a professor specializing in cryptography at Johns Hopkins University, told Ars.

The honeywords proposal has already captured the attention of security experts, some who were quick to point the side effects of such a system. If not implemented carefully, it might allow attackers to deliberately lock huge numbers of users out of their accounts. To limit the possibility of such denial-of-service attacks, the researchers proposed several measures that should be built into the honeyword system.

The researchers went on to point out the obvious, namely that a honeyword system doesn't prevent brute-force and dictionary attacks.

"However, the big difference when honeywords are used is that a successful brute-force password break does not give the adversary confidence that he can log in successfully and undetected," they concluded. "The use of a honeychecker thus forces an adversary to either risk logging in with a large chance of causing the detection of the compromise of the password-has file... or else to attempt compromising the honeychecker as well."

Promoted Comments

All this does is make it harder, which gets easier as hardware improves. What we need is to make it impossible regardless of hardware advances. True 2-factor authentication is the only practical solution: 2 of something you know (pass phrase), something you have (dongle, cell phone), something that you are (bio-metric).

Stop complaining about the cost and just do it for all things financial or important in nature. No one should care that their Twitter or Facebook account is hacked. Accounts like that should not be so important you can't risk it being hacked.

Did you read the article?

Even if a super fast computer were to crack all the passwords in record time, how would it know which one was the real one?

Pretty much every criticism from this thread is addressed in the paper itself. The "Honeychecker" computer doesn't know what the password is, but rather tells the password-storing server which one on the list is genuine (so it just stores an integer for every account). So you don't need multiple password databases.

Further, they propose several different ways to generate passwords that will look genuine and even defeat the idea of grabbing the same account from two separate databases and looking for matches between the two.

These guys have done their research, and their paper is very readable. I highly suggest people actually read it before commenting.

What most of you seem to be arguing is that, rather than install an alarm system, you should make the building more secure. What this is designed to do is provide an alarm system for someone attempting to break in.

Yes, you could make your doors stronger, and ensure that someone can't climb in through the window, but wouldn't you also like to have an alarm system to note if someone was trying to break that window? In most of these cases, you seem to be arguing instead for stronger windows instead of the alarm system. I'm not saying that you wouldn't have both, but arguing against the alarm system because stronger walls are better seems imprudent.

76 Reader Comments

If the same algorithm is applied to each stored password wouldn't it mean that the attacker still has to potentially expend 20x the resources to break a password since they don't know which one is legitimate?

So even if only one password was real and the rest did absolutely nothing it would make that particular data set less appealing?

Isn't much of the value in hacking a database of user credentials the fact that many of those credentials may be used on other properties? Like banking websites, for example? I wouldn't think an eHarmony account is of much value to someone, but the associated login and password is what is truly valuable. A one-in-20 chance is still better than zero.

This sounds like a great idea, a potential problem I see is that most people have shit passwords. If a hacker had to choose between "$8:$282qbdAJK" and "ihatepasswords" they probably should choose the second, since the first is a probably a honeyword and the second real. I think they may be alluding to this in the article where they say the likelihood of cracking it should be the same.

A system probably needs to be developed, such that if a user's password is "ihatepasswords", then honeywords should be similar looking like "ilikedogs" and "letmein". That way a cracker can't easily discern the honeywords.

Entirely useless, and very obvious (not really used, since it confers no benefit.)

Either your db contained enough information to determine the correct password (in which case they check it against that) or it did not, and you must accept any of them.

If it does, it would be more effective to use stronger encryption.

You can determine if someone is attempting to guess passwords anyway, it takes many attempts, and servers log this.

If they are cracking it offline, your DB must be able to differentiate between correct passwords and incorrect ones, which means the cracker can also do this (security by obscurity is a very poor substitute for mathematically hard problems in this situation.)

*edit*

Aside from the minor laugh I had that someone with the name culus posted something similar right before me (my other usual handle is culsu)... It would be far more effective to store the hash on one computer and the salt on another. This way they do not even get the short possibility list.

Taking it to the extreme you could store a single bit of the hash per computer, and secure them all differently. This is not very practical, but if we are involving more than one computer there are far better ways to do what they want.

All security today is essentially based on guessing large random numbers. The way they describe it their second secure system is intended to use a small entropy number to enhance the security of their system.

There is no conceivable reason not to make this a large number, and therefore the number of passwords you get which could be correct from one db but are actually wrong once you take the entire thing into account so vast that it is basically impossible to guess.

This is much better accomplished by splitting the hash between computers. You can then use a standard login attempt limiter to stop all cracking attempts.

If they completely compromise your data you are screwed either way. If they only get one computer and really need two in order to determine the password, there are simply far better ways of doing it.

If a cracker had access to multiple databases, couldn't they just look for the username and then look for the common password? If my password is "dogs" and two of the DBs show "dogs" associated with my username, wouldn't that give it away?

I must be missing something. At some point, the server-side needs to know which is the real password.. Sounds like the authors suggest a specialized system to store that database.

So, we store a database needed to decode another database to detect if the first database is stolen? Can't we just store the first database in the hardened system and be done with it??

Reading the original paper, I gather the idea is to make an entire database of passwords hard to hack. Often drives are stolen. Even if they crack them, they don't know which password is the right one.

I don't see this all that useful to stop some hacker from logging in and trying to bruyte force their way into an account. That is easy enouigh to catch with multiple failures during the auth.

All that said, I'm kind of indifferent on this scheme. It has some utility, but better to spend your effort on a two factor method.

The point is not to improve security (as by using two-factor auth) but to enable administrators to detect the use of stolen passwords more quickly. This is explained specifically in the paper.

Quote:

There are many attack scenarios relating to passwords, including the following six:• Stolen files of password hashes: An adversary is somehow able to steal the file 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.…We focus on the first attack scenario where an adver-sary has obtained a copy of the file F of usernames and associated hashed passwords, and has obtained the values of the salt or other parameters required to compute thehash function H.…We assume that the adversary does not compromise the system on a persistent basis, directly observing and cap- turing newly created passwords and honeywords. (Cer- tainly, the adversary risks detection the first time he tries logging in using a cracked password, since he may be us- ing a honeyword; after that, the ability of the system to detect further attempts to login using cracked passwords may be compromised if the adversary is able to modify the login routine and its checks, or the password-change routine.)Although our methods are directed to the first attack scenario, some of our approaches (e.g., the take-a-tail method) also have beneficial effects on password strength, thus helping to defeat the other attacks as well.

So while the questions raised in this thread may be valid, if this technique were properly considered as but one component of a holistic approach to security, they're really rather moot, and there's no good reason not to implement some of this.

Referring to the ddos lockout drawback they mention,hoow is this that much different from sites that lock you out after a certain # of attempts?Also the focus seems to be on notifying admins that the database is compromised,why not the user?If i got toset the honeypot words half of them would be from the 100 most common password list, you know the script kiddies would get detected by that right away

Referring to the ddos lockout drawback they mention,hoow is this that much different from sites that lock you out after a certain # of attempts?Also the focus seems to be on notifying admins that the database is compromised,why not the user?If i got toset the honeypot words half of them would be from the 100 most common password list, you know the script kiddies would get detected by that right away

Yes but password-protected services can be generally assumed to be under constant attack. If you got to set the honeyword list to common passwords, you'd get unending notifications, and to what end?

The point is to use passwords that won't be attempted /except/ by attackers who have stolen the hashes. That's why it's left to the service administrators to administer. It would then be up to the administrators to alert not just an individual user, but presumably everyone whose password would have been maintained in the compromised database.

"The trick is to make the remaining 19 passwords look as good as the actual password, so the attacker is as likely to crack one of them as she is to crack the real password," Matt Green, a professor specializing in cryptography at Johns Hopkins University, told Ars.

I think, generally, that should read: "...as bad as the actual password..."

Given the following options: "password12345", "xh*4^fnalK%", and "horsebatterygaragebucket"

I could see this system working if the way to tell the validity of a password didn't depend solely on the contents of the password database, but also required a second site-wide secret SK not stored in the db.

For example, let's say the passwords are hashed with 128-bit salts. For a given account, 20 password hashes are stored, 19 with random salts, the 20th with hash(username+SK) as the salt. A normal login attempt would get a username/password pair, attempt to verify against all 20 hashes, and if one matches, verifies that the salt = hash(username+SK). If it verifies, it's a valid login, otherwise, it's a honeyword.

This would increase the complexity and time of both online and offline attacks, which isn't a bad thing.

It would also make sense to have it so that if a honeyword is used, to dump the attacker into a honeypot account as well as alerting the administrators.

Referring to the ddos lockout drawback they mention,hoow is this that much different from sites that lock you out after a certain # of attempts?Also the focus seems to be on notifying admins that the database is compromised,why not the user?If i got toset the honeypot words half of them would be from the 100 most common password list, you know the script kiddies would get detected by that right away

Yes but password-protected services can be generally assumed to be under constant attack. If you got to set the honeyword list to common passwords, you'd get unending notifications, and to what end?

The point is to use passwords that won't be attempted /except/ by attackers who have stolen the hashes. That's why it's left to the service administrators to administer. It would then be up to the administrators to alert not just an individual user, but presumably everyone whose password would have been maintained in the compromised database.

I guess I didn't see it that way.But what if they brought a second factoe into it by populating the honeypot. Lets say your a email site(currently on implementation i can think od dor this method). You make it seem like they logged in and its a full email account and right on top is an email saying hey heres your password to capital one, it suitably ridiculous for a banking password unlike the one that got you into the email but capital one is also set to notify you when someone logs in.which noone should so its like a twofactor breakin detector and socially engineers the hacker by dangling that delicious bank account in front if them

A system probably needs to be developed, such that if a user's password is "ihatepasswords", then honeywords should be similar looking like "ilikedogs" and "letmein". That way a cracker can't easily discern the honeywords.

If you go the 20 password route, you can have generate passwords of varying complexity. The common password crackers' algorithms are readily available, just make 0, 1 or 2 of each level of complexity and the real password will be, for all practical purposes, indistinguishable.

I don't see this all that useful to stop some hacker from logging in and trying to bruyte force their way into an account. That is easy enouigh to catch with multiple failures during the auth.

All that said, I'm kind of indifferent on this scheme. It has some utility, but better to spend your effort on a two factor method.

Actually it does help with brute force cracking. Very large scale systems, such as twitter or linked-in, accept an enormous amount of login requests every second, and brute force / dictionary cracking tools often make use of lists of proxy servers to bounce their login attempts around different IP addresses. Typically, the cracker will define a set number of tries per username, and per proxy IP address, which means that twitter will for instance see 3 failed login attempts from username 1 on IP 1, then 3 failed login attempts from username 2 on IP 2, etc.

With the honeywords though, the attacker will only have a 1 in 20 chance of hitting the right password and 95% chance of triggering a notification to the admins that a cracking attempt is in progress.

I could see this system working if the way to tell the validity of a password didn't depend solely on the contents of the password database, but also required a second site-wide secret SK not stored in the db.

Yeah, from the article:

Quote:

The honeychecker is thus a separate hardened com-puter system where such secret information can be stored.

They explain the rationale:

Quote:

The computer system and honey-checker together provide a basic form of distributed secu-rity. A distributed security system aims to protect secretseven when an adversary compromises some of its systemsor software.

And it's a fair idea. It's tempting to say, "hey, if they get root, we're screwed," but in practice these are complex, heterogeneous networks. There's really no reason to assume the attacker has won just because they take over some of your systems.

This sounds like a great idea, a potential problem I see is that most people have shit passwords. If a hacker had to choose between "$8:$282qbdAJK" and "ihatepasswords" they probably should choose the second, since the first is a probably a honeyword and the second real. I think they may be alluding to this in the article where they say the likelihood of cracking it should be the same.

A system probably needs to be developed, such that if a user's password is "ihatepasswords", then honeywords should be similar looking like "ilikedogs" and "letmein". That way a cracker can't easily discern the honeywords.

The way I'd implement this with client-side javascript running that takes the password, ranks it on a scale of complexity and generates the other 19 around it, starting at "password1" and ending at a 16 character randomly generated password. Make sure one is the username plus whatever symbols/numbers are required for password complexity. Then the collection of passwords gets encrypted and sent over, with the hardened honeyword system getting whatever it needs to determine the real password.

I've been a participant in Project Honeypot for years; I've helped identify hundreds of harvesters and comment spammers by contributing an MX record of my domain and a bit of client website code. Too bad there's not a centralized means for that project to catch the password thieves as well.

The way I'd implement this with client-side javascript running that takes the password, ranks it on a scale of complexity and generates the other 19 around it, starting at "password1" and ending at a 16 character randomly generated password. Make sure one is the username plus whatever symbols/numbers are required for password complexity. Then the collection of passwords gets encrypted and sent over, with the hardened honeyword system getting whatever it needs to determine the real password.

You better generate 20 character random or you will stand out like a sore thumb amidst my LastPass passwords. On the other hand, good luck brute forcing them. You need to crack into my Vault on my computer basically. Also, make sure you only generate the 8 special characters that LastPass does, otherwise again: stands out like a sore thumb.

I must be missing something. At some point, the server-side needs to know which is the real password.. Sounds like the authors suggest a specialized system to store that database.

So, we store a database needed to decode another database to detect if the first database is stolen? Can't we just store the first database in the hardened system and be done with it??

The database that says which passwords are valid (for each user, just a number i, to identify the i-th password). is stored on a separate machine (the "honeychecker"). Presumably it is harder to steal files from two separate machines than from one. The authors point out that the honeychecker only needs to receive inputs (which password was used) and the ability to raise an alarm. Such limited access should help make the system secure.

Note that it is quite common to have two separate machines with password information: many websites have some sort of password recovery scheme. That pretty much implies that somewhere they have a file with unencrypted passwords. Yet it is often the encrypted passwords that get stolen, so apparently the other system is more secure.

Hmm, I like this idea. At the very least I think it's a step in the right direction. Another step would be for any major site to use the major password lists obtained from major breaches this past decade and disallow the use of said passwords (not that people would like having to come up with new passwords, but if your password shows up as not being allowed/on a major password list, you probably shouldn't be using it anyways).

Edit: Of course I mean including common variations of those passwords too. Of course this is undesirable due to the added overhead on the server.... would be cool of all major browsers could implement known password lists and have a standardized check command that could be run client-side before submitting the form for passwords.. same issue with overhead client side this time though... but dunno, just typing as I think anyways.

Edit 2: Also, as people sign up for new accounts, an updated browser list would be a good way to notify them of potential compromises of any other accounts they use that password on, if it has since shown up on the list (obviously only checked when signing up for sites). Granted, shouldn't be using the same password on more than one site, but in reality, it happens all the time.

Main point of the above would be largely to help eliminate/reduce usability of password lists and require more brute forcing. Anyways, using honeywords should include a mix of password list and random generation as well.

This sounds like a great idea, a potential problem I see is that most people have shit passwords. If a hacker had to choose between "$8:$282qbdAJK" and "ihatepasswords" they probably should choose the second, since the first is a probably a honeyword and the second real. I think they may be alluding to this in the article where they say the likelihood of cracking it should be the same.

A system probably needs to be developed, such that if a user's password is "ihatepasswords", then honeywords should be similar looking like "ilikedogs" and "letmein". That way a cracker can't easily discern the honeywords.

I was just about to say the same, only in reverse, since I use randomly generated passwords this kind of thing would be useless if my password "g=6Ro4^N7bcL[2(7kGz{3*$9v8wQts" is in a sea of 19 other "ilovepuppies" "password" "123456" passwords.

If a cracker had access to multiple databases, couldn't they just look for the username and then look for the common password? If my password is "dogs" and two of the DBs show "dogs" associated with my username, wouldn't that give it away?

More importantly, why are you using the same password on multiple sites?

To the people saying the passwords must look like that particular users I counter; how would you know what level of complexity password the user chose? Just use other passwords from password lists or pull them from the available brute force tools for the honeywords. Sure some users have crap passwords, but with a decent generation system that presents a variety of complexities for each user, how is a hacker to detect which is real? Also its largely besides the point, cracking these stolen databases would be largely automated. Even if a human could determine which is the real password, it would slow attackers down by several orders of magnitude.

Wouldn't it make more sense to create Honeypot accounts instead? For example, for every 20 users that sign up on the site, create a honeypot account. If one of those accounts is ever used, then you know there was a security intrusion. You could even give those accounts simpler passwords so they would be cracked first.

While we're talking about passwords, wouldn't it be more secure for the site to just generate a password for each user and not let the user create their own?

This seems like an amazing idea to me. It is one of those things that seems so simple that you'd think we would have thought of it by now.

One thing, though. Secrets have shown to be bad practice in authentication. The hardened server needs an algorithm to both generate 19 passwords, and to arrange the correct password among them. I suppose you generate randomness based on the time of creation, and then don't save that time on the database.

I can't immediately think of a method that doesn't rely on secrets, but I'd like a method of providing the same benefit without needing secrets.

"The trick is to make the remaining 19 passwords look as good as the actual password, so the attacker is as likely to crack one of them as she is to crack the real password," Matt Green, a professor specializing in cryptography at Johns Hopkins University, told Ars.

I think, generally, that should read: "...as bad as the actual password..."

Given the following options: "password12345", "xh*4^fnalK%", and "horsebatterygaragebucket"

I'd say 9/10 times "password12345" would be the best bet.

The smart way would be to change the password salts, and alternate between salts for each user.

Wouldn't it make more sense to create Honeypot accounts instead? For example, for every 20 users that sign up on the site, create a honeypot account. If one of those accounts is ever used, then you know there was a security intrusion. You could even give those accounts simpler passwords so they would be cracked first.

While we're talking about passwords, wouldn't it be more secure for the site to just generate a password for each user and not let the user create their own?

As to the honeypot accounts, they probably already do that. Then what happens when the users can't remember the damn gooble-de-gook password? A tech support nightmare.

The honey-password scheme is not perfect but better what we've got now. I'd also suggest a random number but very large percentage of legitimate accounts scattered randomly throughout the account database. Make it expensive in computer time. Maybe that would hold them off a while longer.

I like TrueCrypt's approach; having to enter your password under duress or, if the duress password is entered, the keys to the encrypted drive are deleted, rendering the entire drive's data useless. I believe TrueCrypt's tact also allows for setting up a 'honeypot' account as well.

For the several posters commenting about how the passwords will/will not look like the other passwords, I refer you back to the article:

[quote]"The trick is to make the remaining 19 passwords look as good as the actual password, so the attacker is as likely to crack one of them as she is to crack the real password," Matt Green, a professor specializing in cryptography at Johns Hopkins University, told Ars.[/qoute]

Those can be easily generated. There is a function in KeePass that generates passwords based on rules from an existing password. Now, this is less useful if a user has a password like "passw0rd", but it is still possible. If the passwords are a randomly generated string of characters, this is a lot easier.

I, personally, use long passwords generated in KeePass with the most entropy possible, for the given length of the password.

All this does is make it harder, which gets easier as hardware improves. What we need is to make it impossible regardless of hardware advances. True 2-factor authentication is the only practical solution: 2 of something you know (pass phrase), something you have (dongle, cell phone), something that you are (bio-metric).

Stop complaining about the cost and just do it for all things financial or important in nature. No one should care that their Twitter or Facebook account is hacked. Accounts like that should not be so important you can't risk it being hacked.

I really like this idea, I'm gonna have to try it out when I tinker around in website building. It seems to work nicely in my head if you expand it out to ridiculous. Unlike two factor sign in. Which sounds really nice and secure, but then I expand that out in my head to say.... 100+ sites... I have 100+ dongles on a keychain.... Better get larger cargo pockets.

All this does is make it harder, which gets easier as hardware improves. What we need is to make it impossible regardless of hardware advances. True 2-factor authentication is the only practical solution: 2 of something you know (pass phrase), something you have (dongle, cell phone), something that you are (bio-metric).

Stop complaining about the cost and just do it for all things financial or important in nature. No one should care that their Twitter or Facebook account is hacked. Accounts like that should not be so important you can't risk it being hacked.

Did you read the article?

Even if a super fast computer were to crack all the passwords in record time, how would it know which one was the real one?

I'm afraid I have to agree with one of the guys near the top of the comments here. If the idea is for the legitimate password to be verified by a hardened system, why not just have the whole database on the hardened system?The only reason I can think of is because the "honeywords" make you a less appealing target. Much as a car thief will go for the car without a steering lock given two almost identical cars next to each other.

I think I prefer the other idea that was floated about in the comments though. What is wrong with storing different parts of the authentication process on different servers? Combined with some IP restricted access and making sure the front end isn't susceptible to injection attacks, this would mean that each server in the chain would need to be root compromised before getting to the next step.

While we're talking about passwords, wouldn't it be more secure for the site to just generate a password for each user and not let the user create their own?

As to the honeypot accounts, they probably already do that. Then what happens when the users can't remember the damn gooble-de-gook password? A tech support nightmare.

I'd like to think that you could develop a protocol for password communication between browser and web site, something that password managers like 1Password and LastPass would plug into. So that the creation (sever side) and saving (client side) of "passwords" happens in the background when you create an account, and the user never knows the password to begin with. Then combine that with a standardized multifactor authentication system for resetting passwords in the event of client-side hard drive failure, theft, bit-rot, etc.

Maybe that wouldn't be bulletproof either, but relying on a human's memory and blind-typing skills seem like the all-time dumbest way to secure anything.

While we're talking about passwords, wouldn't it be more secure for the site to just generate a password for each user and not let the user create their own?

As to the honeypot accounts, they probably already do that. Then what happens when the users can't remember the damn gooble-de-gook password? A tech support nightmare.

I'd like to think that you could develop a protocol for password communication between browser and web site, something that password managers like 1Password and LastPass would plug into. So that the creation (sever side) and saving (client side) of "passwords" happens in the background when you create an account, and the user never knows the password to begin with. Then combine that with a standardized multifactor authentication system for resetting passwords in the event of client-side hard drive failure, theft, bit-rot, etc.

Maybe that wouldn't be bulletproof either, but relying on a human's memory and blind-typing skills seem like the all-time dumbest way to secure anything.

And people who want to sign on with more than one device? Essentially this stuff would have to be stored centrally, meaning that although perhaps each password is more time consuming to crack, once cracked it opens up all other passwords? Seems like an eggs in one basket approach to me.

I think the easiest solution to making the honeywords hard to distinguish from the legit password is to have several sets of passwords varying from "good" to "why did you use that password?!"

So if they honeyset includes "ihatedogs1,"dragonseverywhere!" "the53thing234you662said" and "q2-87&&-02983jhf" (and several others of similar and varying complexity to those already on the list)

Then how would the attacker know which one? They'd have to guess how "complex" you were -- which could be done if they had several other cracked password lists you were on, but that requires a lot more effort, and even then there'd still be a couple on the list that were that complex.