Fake users in database for compromise detection

Question

I have read of sites* adding fake users to their databases and then monitoring their usage. One of these fake users being used or even attempted login may mean database compromise etc.

This sounds like a good idea for detecting issues after they occur, and I plan on doing this myself. Is it actually a good idea though?

Would it be useful to scan the web, using google alerts etc, for the fake users password hashes and email addresses, and possibly unique strings inside the codebase?

*Sorry, I can't remember where. Linode perhaps.

edit: For clarity, 'users' being those who log into a website. I could add users similar to johnfakeuser@fakedomain.com with a dictionary type password. If that user is logged in, then investigate and reset all user passwords etc. If it is only an attempted login, then it is a flag of something to investigate further, but maybe just a lucky hit.

Regarding web monitoring, I could monitor pastebin etc and look for the password hash for those users or unique strings found elsewhere in my code/db. This could be independent of the fake user idea, as I could just monitor for real hashes (e.g. a low level admin account).

Answer 1

Creating a honeypot is a common used technique in information security, though probably not the best of ideas for a production environment. Apart from the fact that you add potentially new risks to your application, there may not be much need for such a trap.

Failed logins can be monitored by most applications (and/or server daemons) which should give you more than enough insight without putting your application at risk.

To state the obvious; brute force attacks are (unfortunately) a common phenomenon and are likely to hit your application anyway.

Answer 2

I'm a little late to the game on the question, but since I mostly disagree with the other answers here so far, I'm presenting a new one.

The main things I disagree with from the other answers are:

1. Adding users to the DB is not the same thing as creating a honeypot. (It's probably possible to take a definition of honeypot and interpret it in such a way that this could be considered a honeypot, but I think it's a stretch.) Suppose you add 10 users just for your QA team to use for testing. If you notice that any of those users have logged in outside of normal testing hours, or from IPs that are not expected, you would be accomplishing the same thing, and surely you wouldn't call those QA users a honeypot.

2. Adding additional users to the system does not make the system more vulnerable. If that were true then every time a new user creates an account the system would become more vulnerable. That would be pretty sad if it were true!

As for whether adding users to the system would be helpful, the answer depends on what your application actually does. If your user database is compromised, which would the attacker rather have: the information contained in the database (such as usernames/passwords/email addresses) or would they rather have access to the website? Consider:

• If the site handles banking, then an attacker will likely try to login with many accounts and move money around or gather account information. (The "extra" users may have login attempts in this case.)
• If the site is just a free forum, the attacker will probably not care about logging in and will instead consider selling the email addresses, or try to brute force the password hashes to guess passwords on banking or e-commerce sites. (This might be the most likely scenario.)
• If the site has interesting paid content that the attacker wants, they might chose a single user and login with it. (Which is unlikely to be one of the "extra" users.)

So, in the first case, monitoring the "extra" users might be somewhat helpful, but in the majority of cases it probably wouldn't be.

That being said, if you still want to try it, perhaps the most effective approach is this:

1. Create two new email accounts with very difficult to guess addresses, extremely difficult passwords, and then set them up to forward to your main email account that you check frequently.
2. On your site, create a new user with each of those email addresses, both with very difficult to guess usernames.
3. Give one of the users a very hard password, and give the other user an easy password.

Now you've accomplished two things: if either of those users ever logs in (likely it will be the one with the easy password), then your DB is probably compromised. Or, if you ever receive an email to one of those account's email addresses, your DB has likely been compromised, and the email addresses were probably sold.

Final thought: above where I mentioned the most likely scenario (the attacker attempts to gather user/email/passwords for use on other sites), in that case they may never login or sell/spam the email addresses, and if so, unfortunately it will be pretty difficult to detect this outside of monitoring all access to the DB server.

Answer 3

This could be useful for Credentialed Vulnerability Assessment, but on a production side perspective, you're putting your application at risk. This could be a possible attack vector for an attacker.

Attacker may gain access to these accounts, and may find ways to exploit and gain administrative rights or privilege escalation.

The concept you were trying to say is a Honeypot (monitoring what could the attacker do), but honeypots are designed to be compromised. I believe so that you don't want your application to be compromised.

1 rule in Application Hardening is disable unnecessary accounts/default accounts/guest accounts/shared accounts.

Answer 4

It seems like a good idea to me, but with a caveat: You need to make sure that it doesn't make your system MORE vulnerable. I realize that this is technically impossible as another user account is another way in, but here's what I suggest if you decide to implement it:

• Don't use a common username, such as admin. This is likely to get hit by passive multi-host attacks just scanning.
• Make the password insanely, even impractically long and complex seeing as there is no intent for the account to be used.
• Monitor attempted accesses as well as successes, although you have bigger problems if there's a success.
• Finally, one of those bigger problems: MAKE SURE YOU HASH YOUR PASSWORDS!!! This should be common sense, but you'd be surprised. If your passwords are not hashed, then a database compromise WILL give access to all accounts.

Final note: The reason it's so important to go for attempted rather than successful accesses has been mentioned by other users: Privilege escalation is likely almost certainly possible if they can get in.