Honeywords — Honeypot Passwords

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

Comments

Re:How does this work?

[zindorsky]

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.

Re:This... is a very good idea.

[LordLimecat]

Salts and hashing algorithms arent supposed to be secret. The only requirement for the salt is that it be unique, and the only requirement for the hashing algo is that it be secure.

Re:This is an ok idea, definitely not a great one

[gamanimatron]

Some responses (informed by the actual paper):

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.