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?