I'm tossing an idea around in my mind. I want to bounce it off the community to see if this holds any water.

First - the OWASP guidelines never specify any method of action when you're dealing with registrations and password resets. Obviously this has come up a few times in several forums - including stackexchange.

So the problem is really the question of how much security are you willing to sacrifice to keep the frustration level of the user experience low. After an admittedly superficial mental review of the problem, I'm wondering a few things.

Let's set the stage with example.com, who follow the existing OWASP recommendations to the T.

In the case an attacker has an email address and uses it to attempt to find out whether or not there is an associated user account by attempting a registration. My question is as follows: Suppose you used a hybrid of intrusion attempt detection and a honey pot. So - you have a registration attempt that throws some red-flags in that it is not from a usual IP for that user, not from the usual geographical area for that user, and the client fingerprint is different. Obviously, in the case that a user already has an account, they're most likely not going to attempt to register again.

In the situation where all or most of these red flags are present, why not just allow the intruder to continue with the registration process, all the way to the completion of the account and full setup. Yes, this causes some issues with figuring out how exactly you're going to have 2 accounts with the same username (possibly dictated simply by username/salted_pw as the key difference). But in this manner - the attacker would most likely give up. You could then inform the original user, inform them and get their verification, and keep the honeypot account indefinitely until either A) the time dictated by the site before the account is closed due to non-use has passed or B) the attacker continues to attempt creating honey pots in hopes of finally landing on the real account. In this case, you could simply say - after 3 false accounts, that user is then banned for site abuse (but the real account is kept open for the user - informing the user of the issue - suggesting some actions to better secure the account and putting the account under close watch). Password reset would follow a similar honeypot-like path.

In this case - can anybody see any major issues or problems with implementing something like this? I mean - from a security standpoint - would this actually be a feasible method of deterring such attacks while keeping the user's anonymity?

  • 1
    Just my personal opinion, but it seems from your description that your goal is to use a honeypot to exhaust the attacker's time. I don't see any reason here to do anything other than lock out the brute force attempt. That in itself consumes the attacker's resources. Honeypots are better used as an intelligence gathering tool to see what an attacker will attempt to do if they gain access.
    – nbering
    Feb 11, 2019 at 1:08
  • 1
    If this were proposed on my team, my biggest concern would be the odd failure mode that would appear to be if a legitimate customer somehow ended up in the honeypot. Like, maybe there was a bot on their network attempting to brute force the system and so their IP was flagged. "You've been locked out" would be easier to resolve than facing a registration page for an existing account.
    – nbering
    Feb 11, 2019 at 1:15
  • Updated my answer
    – Bokis
    Feb 18, 2019 at 3:22

1 Answer 1


From a security standpoint try to understand what advantages a honeypot adds.

When you design your security you should try simulate real world scenarios with an intelligent attacker and how your honeypot would work.

For Starter's your security stands on obscurity which is usually not preferred (can be an ambiguous subject). In your case if the attacker is aware of the honeypot he will just not be bothered.

Also consider that adding a honeypot opens a new surface for attacks.As mentioned by @nbering a legitimate user could be locked out or worse an attacker could try to lock out your users with spoofed ip while trying different emails.

If your security concern is for an attacker enumerating valid emails, simply you could inform if the registration was successful on the provided email.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .