Here’s a new twist on password hashing schemes. The Honeywords Project introduces what I think is an interesting, but ultimately futile, approach to password security. There’s a paper linked that describes the scheme (worth reading) and an FAQ that doesn’t answer any questions I or anyone interested in the scheme is likely to ask (not worth reading).

background

Here’s a rough sketch of the general idea. Install an impenetrable server. Copy your password database to this server. Add lots of fake passwords to the password database on your application server. Change the frontend servers to double check the user’s provided password is the real one and not one of the fakes by querying the impenetrable server. If that check fails, red alert! Your password database has been stolen.

Probably most relevant today in the context of web sites, but generalizes to any authentication server (ssh, LDAP, ...).

smart and not smart

Some parts of this scheme are smart. Some are less so.

Let’s start with the idea of moving your authentication service to a server that hackers will be unable to break into. Smart. I encourage everyone to migrate their password database to an impenetrable server.

But the described scheme implicitly encourages/condones leaving your users’ real password hashes on the vulnerable app server. Not smart. When a user’s password is stolen, it’s not just bad news for your service. If, like most people, they reused that password somewhere else, your ability to detect a stolen password database does little to protect them. The tragedy of the Gawker leak was not that hackers could post fake comments to Gawker, it was that hackers could use those user/password pairs to login to a bank. Or worse yet, post fake comments to reddit.

It’s also crazy complicated in relation to the security provided.

making it hard the easy way

Here’s a simpler idea that provides at least as much, if not more, security.

Install an impenetrable server. Move (don’t copy) your password database to this server. Change the frontend servers to query this server to authenticate users. Continue computing your (iterated, salted, bcrypted, ...) hashes on the frontend servers to distribute the load. You can funnel all the password hash checks to a single server (or one per region) because it’s very fast. Also provides an easy place to monitor or ratelimit online password guessing attempts.

You need to provide three operations. 1. Check a hash. 2. Change a hash. 3. Reset a hash. Actually, 3 is redundant. The frontend can generate a new password and change it via 2. (If we assume the frontend is compromised, the attacker is already capable of impersonating any user at the app level, so there’s little to be gained by requiring the frontend to supply both old and new hashes in order the change a hash. But if it makes you feel better, do it that way.)

Assuming our impenetrable server is impenetrable (an assumption in all of these schemes), we have now completely sealed our password hashes away from the bad guys. If you assume a scenario in which this server is compromised, then you should assume the attackers will also steal the honeywords list and your efforts to detect them will fail.

cynical view

RSA (the company) also happens to be peddling a distributed password checking system that’s a lot like the simple scheme above, but also needlessly complicated. Splitting the impenetrable server into two impenetrable servers sounds like a great idea, but let’s be realistic. These servers shouldn’t be exposed to the open internet. They should be running a minimal set of services. The only weakness such a server should possibly have will be in the common service running on both of them, the password hashing service. Piggy backing on the news of the LinkedIn password break is rather disingenuous, since there are so many simpler improvements that can be made.

I can’t help but think the honeywords project is an attempt to stir up interest in crazy exotic password storage schemes. I agree that we’re still at a point where lots of companies are using woefully inadequate password hash security measures, and it’s good to get people to upgrade, but when developers’ first introduction to these ideas is insanely complicated and comes with a six figure consulting fee, that’s a turn off. It does a disservice because then people turn their back on the idea and stick with the pitiful hashing they’re already using.

Analogy: I leave my wallet on the bar and go to the bathroom. I come back, and shocker, my wallet is gone! Shortly thereafter, I get a call from ACME telling me that wallet would have been safe if only I had purchased their two-ton Safe of Steel. True, but I could also have protected my wallet by keeping it in my pocket, a much simpler and more affordable solution.

footnotes

None of this does anything to protect your app server from compromise. We are generally assuming that the app server is already taken over and are interested in protecting the users’ passwords by protecting their hashes. I think a critical distinction to keep in mind is that the responsible thing to do is not to simply protect our own service (as the honeyword idea does), but also the user.

Note also that the attacker can simply use the frontend server to collect and log plaintext user passwords as users login. That’s a different problem.