Administrative and Maintenance Tools - Multiple Account Detection & Prevention

It happens all of the time. Some members will make multiple accounts to back their own opinion or get an extra vote in a poll. Here's a modification that will detect and prevent multiple accounts, as well as notify the administration about multiple accounts. Inspiration for this modification came from the work of MPDev (creator of the Multiple Account Login Detector) and randominity (creator of the Multiple Account Registration Prevention). This is basically a combination of those two modifications but with new and improved functionality.

This is not an update to the "Multiple Account Login Detector (AE Detector)" nor is it an update to the "Multiple Account Registration Prevention." If you have either one of these (or both of them) installed, you should uninstall them before installing this modification.

With the initial release of Multiple Account Detection & Prevention, I believe that I have fixed previous bugs/complications as well as improved the efficiency and logic of the code. This is my first publicly released modification. I would appreciate any comments and suggestions!

Confirmed! This works perfectly on all vBulletin 3.6, 3.7, and 3.8 versions.

Unfortunately, I cannot give support right now. I may be able to help periodically, but until my schedule yields some more free time, I won't be much support. Please check back in a week or two.

Basic Details
File Edits: None
Template Edits: None
New Files: 6
Hooks/Plugins: 3
Global Phrases: 36
Install Time: 2 Minutes or Less
Install Difficulty: None, Very Easy

Features and Settings
- Login Detection
- Registration Prevention (Multiple Methods)
- Ignore Child Accounts
- Ignored Users
- Ignored Usergroups
- Ignored ISPs
- Prevention Usergroup
- IP Address Based Prevention
- Extended IP Address Prevention
- IP Address Time Inclusion
- Banned Account Check
- Primary Banned Usergroup
- Cookie Expiration Time
- Cookie Refreshing
- Cookie Name
- Cookie Reset
- Multiple Account Reporter
- Reports via PM
- PM Report Recipients
- Reports via New Thread
- Forum for Report Threads
- Verbose Mode
- BB Codes: LIST, URL, CODE

How it Works
With every newly recognized login/registration, an account-counting cookie is set (or added onto) with the member's User ID. Depending on the settings, Multiple Account Detection & Prevention will analyze the cookie during login/registration to see if there are any multiple accounts.

Login Detection offers cookie-checking and reporting. Registration Prevention offers the same thing, plus more advanced features. First of all, when it prevents an account from registering, it actually moves the registrant to the Prevention Usergroup so that the administration can review the case. This also allows for customized privileges for recognized multiple registrants. Registration Prevention also has IP address detection which finds out just as much information about users. Depending on an administrator's preference, this modification can also reban a new registrant if one of their previous accounts has been banned. In fact, if the administration wishes, multiple registrants can simply be denied registration all together.

Whenever there is a detection/prevention, the modification will report the information to the administration through private messages, a new thread, or both (depending on settings). The Multiple Account Reporter can be any valid user.

Known Issues
- vB Optimise users: Reporting via thread seems to get messed up by vB Optimise, so try reporting via PM instead.
- PhotoPost vBGallery users: The registration handling appears to not work properly when PhotoPost vBGallery is enabled.

From what I can tell, these known clashes have been caused by the other modification's coding. The author of vB Optimise will not even work with me to fix it. Until they improve their coding, I'm not sure if I can do anything about these issues. As far as I know, administrators that do not use the above modifications will not have any problems.

Installation / Upgrade
Unzip the package (madp.zip), upload the files to your forum location, and import the product file (allow overwrite if upgrading). Please read the ReadMe.txt file that is packaged with the modification for more information.

Please remember to mark this modification as installed if you use it!
If you like it, nominate it for the Mod of the Month!

Thank you!

[Kiros72]

Originally Posted by ItsikN

Hi,

I turned off the registration preventation option since at the moment I want the app only to to detect and report duplicates without preventation.

However, the app reported today the following "The new account has been moved to the Prevention Usergroup" and moved it into the "COPPA users awaiting..."

I'm using VB 3.8.3.

Any advice?

Thanks.

Well I believe that is the default option for registration prevention. Double check to make sure that the prevention is completely disabled. If it is, please list all other modifications that you have installed. There might be some clash with registration-related modifications.

[ItsikN]

Originally Posted by Kiros72

Well I believe that is the default option for registration prevention. Double check to make sure that the prevention is completely disabled. If it is, please list all other modifications that you have installed. There might be some clash with registration-related modifications.

OK, first, I prevented it just by marking "No Prevention" under the "Registration Prevention" segment, should I do anything else? maybe remove the usergroup id number from the "Prevention Usergroup" segment?

I'm using the following mods: Album Pictures - Forum Home, AME - The Automatic Media Embeder, PB Watermark Album Images, Quick Auto Image-Resize (Posts & Signature) and Watermark Attachments.

That's it.

[Kiros72]

Hmm. I don't see anything that could be affecting it. Could you enable verbose mode and copy the report next time it uses any sort of prevention method?

[ItsikN]

Will do.

Thanks.

[Matt Lathrop]

Could anyone get this working with FB Connect login? Or Kiros do you know a work around?

[David Bott]

Hello...

Silly question...A person has to log out and then log back in for the cookie to be set correct?

What I mean is, if a user has the REMEMBER ME box checked to remember them, the person gets auto logged into the site when they return. As such, it will not set the new cookie until they LOG OUT by clicking log out or clearing their cookies and then logging back in. (it does not just update upon return.)

I am asking for I just changed over from the other AE Detector and it also used IDStack. I did not want an issue so I changed my to something like MySettings. (Could I just use the old info in IDStack?)

Thanks

[David Bott]

SUGGESTION...

When a catch is made via IP, can you please include the host info name for the IP? It would help to determine if it may by a proxy for a company.

Also in the verbose info...it says by IP, but also could include the IP address again with the domain info.

Currently looks like... Caught by: IP Address

Could look like... Caught by: IP Address XXX.XXX.XXX.XXX (Domain.com)

Looking forward to future advancements.

BTW...I ask for AVSForum.com is a very busy site with a lot of companies that come in. We see a lot of spammers and what have you as you may guess.

[ItsikN]

Originally Posted by Kiros72

Hmm. I don't see anything that could be affecting it. Could you enable verbose mode and copy the report next time it uses any sort of prevention method?

Hey Kiros,

Today it happened again, this is the plot:

[ :: Verbose Information :: ]

[ Prevention Method Information ]

Selected Method: No Prevention
Prevention Usergroup: 4 (Found)
Primary Banned Usergroup: 8 (Found)

[ Cookie Information ]

The account-counting cookie (IDstack) was not found.

[ Capture Information ]

Caught by: IP Address

[ Verbose Messages ]

[ Dev Information ]

Verbose Message Bitfields: 0

[r2r]

Great mod! really useful, thanks! I have so many spammers sign up to my site, so it is really useful having somthing to prevent it.

[Kiros72]

Originally Posted by Matt Lathrop

Could anyone get this working with FB Connect login? Or Kiros do you know a work around?

I didn't know that the Facebook modification broke the modification. I'll have to download it to see if there is some kind of workaround. I might not get the chance to within the next couple of days. I'm working long hours and I'm struggling to get started with school, so I have little time on my hands.

Originally Posted by David Bott

Hello...

Silly question...A person has to log out and then log back in for the cookie to be set correct?

What I mean is, if a user has the REMEMBER ME box checked to remember them, the person gets auto logged into the site when they return. As such, it will not set the new cookie until they LOG OUT by clicking log out or clearing their cookies and then logging back in. (it does not just update upon return.)

I am asking for I just changed over from the other AE Detector and it also used IDStack. I did not want an issue so I changed my to something like MySettings. (Could I just use the old info in IDStack?)

Thanks

Well, just as in the older AE Detector, the cookie is set during login. Nothing happens during logout (in the modification, that is). The cookie is not cleared since it uses a separate cookie, but if I remember correctly, any cookie name that is prefixed with your vBulletin cookie prefix will also be cleared during logout. For instance, if you have your vBulletin cookie prefix set to vb_ and your account-counting cookie name is vb_IDstack, it would be cleared during each logout. However, I also think that I put in a warning system, so if you accidentally have the cookie prefix in your cookie name, it will let you know either in the settings panel or in the reports. I'm not completely sure where because it's been quite awhile since I worked on that specific code.

Originally Posted by David Bott

SUGGESTION...

When a catch is made via IP, can you please include the host info name for the IP? It would help to determine if it may by a proxy for a company.

Also in the verbose info...it says by IP, but also could include the IP address again with the domain info.

Currently looks like... Caught by: IP Address

Could look like... Caught by: IP Address XXX.XXX.XXX.XXX (Domain.com)

Looking forward to future advancements.

BTW...I ask for AVSForum.com is a very busy site with a lot of companies that come in. We see a lot of spammers and what have you as you may guess.

Ah, a good suggestion. I'll add that into future versions. But as I've said in earlier words, I have very little free time, and my next version is planned to be a huge release with database functionality. I have a lot to add on, so it may not make it into the very next release, but I'm not even sure when that will be at this point in time. But nonetheless, tis a good suggestion and I'll be trying to implement it in the future.

Originally Posted by ItsikN

Hey Kiros,

Today it happened again, this is the plot:

[ :: Verbose Information :: ]

[ Prevention Method Information ]

Selected Method: No Prevention
Prevention Usergroup: 4 (Found)
Primary Banned Usergroup: 8 (Found)

[ Cookie Information ]

The account-counting cookie (IDstack) was not found.

[ Capture Information ]

Caught by: IP Address

[ Verbose Messages ]

[ Dev Information ]

Verbose Message Bitfields: 0

That's quite odd. Not the verbose information alone, but coupled with the situation. I'm going to have to investigate this. If you would like me to, please contact me through PM with login details to your forums.

Originally Posted by r2r

Great mod! really useful, thanks! I have so many spammers sign up to my site, so it is really useful having somthing to prevent it.

Thanks for the complement ^^
Glad I could help out a bit!