Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
    
This isn't a bad idea, but I'm not sure if it's worth it. I think it will be difficult to balance false-positives and false-negatives regarding logins/login attempts. If you add fake users such as "test:test", you will get a lot of login attempts because of bruteforce attacks. If you use "test:super!complex&password", an attacker may not be able to crack it. That leaves "super!complex&username:test", which will tip off any attacker that pays a little bit of attention. It's also unlikely that you will be able to find a leaked db via google. – tim Jan 17 at 20:30
6  
Actually, it seems you are willing to build an honeypot database server. I would not use a production database for such a use: imagine someone using your fake account to escalate toward some real data. I would merely use a dedicated database for such thing. – WhiteWinterWolf Jan 17 at 20:57
4  
The term I have heard used is: honeyusers – schroeder Jan 18 at 1:25
1  
It seems many major sites already do this with real users, by using some heuristics to predict whether an account was compromised. I travel a lot, and when I log in from a different country than last time, may sites I use go into panic mode and require additional confirmation through e-mail or phone that it's really me who just successfully logged in. – vsz Jan 18 at 5:15
1  
@tim If you had a few users with plausible but not common names (e.g. mixing national heritages like "Miguel.O'Donnell"), and guessable (near-dictionary) but not common passwords, then 2 of these users trying to log in would be a pretty solid flag. – Chris H Jan 18 at 9:23

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.

share|improve this answer
2  
It'd be a big risk if your application is a platform for storing sensitive information (e.g: LEEP - cjis.gov/CJISEAI/EAIController) and you'd be using weak passwords on purpose. Otherwise there ain't really a risk depending on the type of website. Because otherwise every new user would be a risk always. – O'Niel Feb 11 at 16:23

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.

share|improve this answer
2  
For a website where users can create new accounts (which is how I read the question), these accounts are unprivileged and may be created by untrusted people anyway. Instead they detect leaked user databases. – Chris H Jan 18 at 9:26
2  
Clarified question - I did mean a end user, not the db user. I don't think this would add any issues - any user can create an account on my site and in theory, my fake user would be identical so not to look fake. – Paul Jan 18 at 11:40

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.

share|improve this answer
    
Clarified question - I did mean an end user, not the db user. Regarding privilege escalation, I don't think that is a worry (in the website user context). If it is, then I've got bigger issues :) – Paul Jan 18 at 11:44
    
I would add to the list to restrict the honeyuser's privileges to the absolute minimum just in case they would get in. – Stef Heylen Jan 18 at 11:46
    
@Paul Privilege escalation is always a worry if the user has any kind of (even indirect) write access to the system. For example if a daemon running as root can be told from the website to write to example.com/~badguy, then it's likely that badguy could have it write to /~badguy/../~MrPresident/. – VirtualDXS Jan 19 at 1:11

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.

share|improve this answer
    
Thank you for this, it is more inline with what I was considering. Option 1 is my use case, it's not financial but does have business intelligence issues that could be leveraged in bad ways. When I read about Linode, they had found a known hash of theirs on a darknet forum (being sold I think) and this is how they knew they had been compromised, so fake users seems to provide double chance of discovering compromises after the fact. – Paul Feb 12 at 9:26
    
If any of your hashes are found on the internet or the darknet, you actually wouldn't need to create extra users to detect that. Any of the hashes of your regular users would suffice, since the hashes should only be accessible by your DBA and the application. The main advantage of the fake users is you know they should never have a login attempt, and you should never receive an email to their address. If you do, it's a pretty good indication that something is wrong. – TTT Feb 12 at 15:24
    
After thinking about my last comment, it made me realize that you may not even need to distinguish between the 2 fake users I mentioned in my answer. (One with hard password, one with easy.) Any login attempt for those users should raise a flag, whether successful or not. The user with the easy password is probably not needed, unless it is easier for you to track successful logins for some reason. In your particular case, you could create thousands of fake users if you wish, to increase the probability of someone attempting to login with one of them. – TTT Feb 12 at 15:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.