If the Honeychecker system has to be secured in order to guarantee that the whole system is secure, why not store the encrypted passwords there in the first place ? It seems to be manufactured complexity.
If you keep the encrypted passwords in one "secure" place and the honeychecker in another "secure" place, then the system is secure unless both systems are compromised.
A. It doesn't do a lot to 'secure' the password credentials (in the way most people think of the term). It just tells you that someone tried to login with a honeywords. What happens then is a difficult process.
B. It's only belt-and-suspenders redundant to the extent the difficulty of cracking the honeychecker server is independent of the regular login server. It's certainly beneficial that it has a much simpler API, but if your honeychecker is just a different Ruby Gem hosted on a different Linode (for example) the benefit are lessened.
If the honeychecker is compromised you are no worse off than without a honeychecker (unless it lulls you into a false sense of security) but as long as it's not hacked it adds detectability. Not sure it's worth the effort but it's an interesting idea.
Indeed. Their FAQ says as much in question 6, and question 7 tries to make it out as though it maintaining a separate (actually secure?) honeychecker actually worthwhile pursuit, because then attackers who don't bother to look at your login code after compromising your box can sometimes be detected. It seems like a bit of a longshot, though. I would expect the attacker to be at least a little curious as to why each user has 20 passwords.
The vulnerability surface of the honeychecker may also be significantly smaller than that of the principle server.
It's possible that the password compromise is affected through other means as well (backups, database compromise, etc.), In which case the honeychecker van help validate this.
A similar approach would be to have sentinel accounts which aren't ever accessed, and which would trigger alerts if they were.
