Administrative and Maintenance Tools - Multiple account login detector (AE Detector)

Mod of the Month winner!
Top 10 most installed mods for vB3.6!

Same plug-in found here:

https://vborg.vbsupport.ru/showthread.php?t=107566

There are no differences as this plug-in works with both 3.5 and 3.6 versions of vBulletin.

If you are like me and migrated from .threads, a common modification was an "AE detector", a simple mod that saved a cookie of a history of ids logged into on your site. If someone logged into more than one account, you got a PM letting you know that your site was being accessed from multiple accounts.

Over the years this was very helpful in identifying users who were posting under multiple accounts (alter-egos!) and users who would return after being banned.

You might be wondering why I don't use the vbcookie call - well, thats because on logout all vB cookies are cleared, so we need to store a cookie that is not effected by the login/logout process.

New Installation
1. Add New Product with attached XML
2. Go to vBulletin Options -> AE Multiple Login Detection Settings and set your specific settings.

Time to install: Easy - 2 minutes.

Upgrade
If you installed this as a Plug-in manually, you can delete that plugin and install this Product, just make sure to go into the Options and set them accordingly.

I hope you find this useful and will click INSTALL if you use it; should it prove useful to enough people I can look at making this installation more automated without the need for edits and an Admin Options page.

To upgrade you will want to reimport this XML file and edit your options accordingly.

1.0.3
-----
. Added a check to ensure that users weren't deleted when reporting violations
. added htmlspecialchars_uni call to username

Note: I am unable to get the call to construct_phrase with $vbphrase['multiplelogin_alert'] to work reliably, as such the $message variable is still set manually inside the plug-in and not via the phrase. If anyone has an idea of why this might not always work, I'm all ears.

1.0.2
-----
. Updated to include exclusion groups, users
. Changed so PM is sent by ae sender id

1.0.1
-----
. Released as a Product (thank you PHPGeek2k3 for your help)
. Added option to post to a forum versus send a PM (or both)
. All settings moved into Admin Option

1.0.0
-----
Initial release.

[Spinball]

Originally Posted by mfyvie

Just to give everyone some advanced warning: I've had permission from MPDev (developer of this mod), to overhaul and extend it. I've started this process and am testing it on my own system. When it is ready, I will release the "enhanced version".

I'm doing this because I get about 3-5 duplicate accounts per day and the workload with having to deal with this is too much.

Examples of new features being added is the ability to send "please explain" PMs to offenders who have been detected with multiple accounts. This cuts down on the amount of work someone has to do - they simply wait for the reply. Notification messages can also be appending to an existing thread (rather than a new thread started each time).

The changes will also mean that the mod will be fully phrased based and the notification messages themselves will contain more useful information as well as links to various handy functions (like ban).

I'm also looking at making it more database-based - in that each cookie will be assigned a unique serial number. This will bring many advantages - such as the ability to exempt a particular computer from the check, rather than having to exempt the users themselves.

Just wanted to let those of you who are interested know - so you can watch out for it when it is released. I can't give you a promise at this stage when that will be - maybe a couple of weeks.

Excellent - thanks.

[YabbaDabba]

Originally Posted by mfyvie

Notification messages can also be appending to an existing thread (rather than a new thread started each time).

MOST excellent!

Also, and you may have anticipated this already, but it would be useful to allow admins to reset the AED if their userID counts have been reset. Perhaps this means a timestamp or AED version number in the cookie.

And once an overlap has been reported for a particular pairing, it would be useful to stop further reports of that particular pairing. That is, once users A and B are reported as overlapping, it isn't necessary to report it again. But this should not stop new overlap reports for A and C, or B and C, from being made.

[mfyvie]

Just an update on this:

I've completely rewritten the back-end (the old mod was only the backend), but I've yet to write the front end which will allow easy management of all the reports, cookies etc. At the moment the new version is running on my production forum (around 3000 visits per day), so I'd like to keep running it to make sure it is stable and works as it is supposed to. So far, so good.

The new features are too numerous to mention, but it does import the old cookies from the original version, so there's a pretty much seamless upgrade path between the old and the new version.

I'm not sure when this is going to be ready, but I would guess about 1 month, most of the difficult logic and tricky testing was done in the backend, so writing the front end should hopefully be simpler.

Now onto your suggestions:

Originally Posted by YabbaDabba

MOST excellent!

Also, and you may have anticipated this already, but it would be useful to allow admins to reset the AED if their userID counts have been reset. Perhaps this means a timestamp or AED version number in the cookie.

Cookies contain a unique cookieID which ties back to the database, userids on the cookie and the first visit on that cookie, as well as an MD5 hash of the cookie contents. Everything is based on userids, so to be honest if someone resets all their userid numbers (why would someone want to do this) then it won't work anymore. Thankfully the fix in this situation would be easy - the admin would have to drop all the records from the AED tables (can someone tell me what AED is supposed to stand for, I should really know since I'm writing it - the A and the D I get, but the E?).

If during the login process the cookie ID on the PC is not found in the DB then it will be removed from the machine and a fresh cookie issued - in this way it would solve the problem you've just described. This functionality has already been tested.

Originally Posted by YabbaDabba

And once an overlap has been reported for a particular pairing, it would be useful to stop further reports of that particular pairing. That is, once users A and B are reported as overlapping, it isn't necessary to report it again. But this should not stop new overlap reports for A and C, or B and C, from being made.

I've implemented this a little differently. Firstly the same users logging into the same cookie will not raise another report (that is also how it worked in the old/current version). Before you had the choice just to exempt users, but now you can exempt a cookie as well. The advantage of exempting a cookie is that all subsequent users won't be reported (unless they go to another computer and log in). This is useful for a PC where many people share it (like a common PC in a work cafeteria for example).

Of course if you've exempted a cookie and it gets cleared, then you'll get the report again unless the users have been exempted.

The main thing that used to bug me with the old one was having to retrieve the userids and enter them into that comma separated list. This will be much easier in future! The system also automatically PMs offenders and asks them to explain. If they don't, you can have them automatically banned or suspended within a configurable period of time. There's also an option to immediately ban users who register from a computer where a banned user has logged in...

[nocte]

Hi, here are my suggestions:

• The reports should be searchable. So if you enter a specific user name in the searchbox you should find the reports.
  
  
• The system info (e.g. browser, os, screen resolution, ..) as well as the IP-Adress(es) should be within the report. In some cases this might be helpful. It would be also helpful to have for each posting the system info saved to have a thrid way to compare users (appart from shared IP-Adress and cookie)
  
  
• The first save date of the cookie should be reported.
  
  
• I'd love to have a automatic cronjob that searched once a day for users who were during the last 24 hours online with the same ip-adress. We have a very huge forum that is a few years old so searching for a specific ip often shows dozens of users who accidently had the ip-adress during the last years.

[mfyvie]

Originally Posted by nocte

The reports should be searchable. So if you enter a specific user name in the searchbox you should find the reports.

The actual interface will be concerned more with dealing with the current issues - such as tracking new reports and resolving them, so it won't deal too much with history. However, each time an incident is reported it can be sent as a PM, started as a new thread in a given area or appended to an existing thread. Each report contains detailed information about each user found on the cookie. If you keep this information you can then use the advanced search features of VB to locate the info you need.

Originally Posted by nocte

The system info (e.g. browser, os, screen resolution, ..) as well as the IP-Adress(es) should be within the report. In some cases this might be helpful. It would be also helpful to have for each posting the system info saved to have a thrid way to compare users (appart from shared IP-Adress and cookie)

I have deliberately left out IP address and browser info from the reporting. Why? IP address is becoming more and more useless as a way to track users - that's the whole idea behind the cookie-based approach. Many users are logging on via proxies (for example when they are at work), or are using dynamically allocated address which are changing often. Including the IP really would be of limited use.

What about browser details? Since our cookie is tied to that specific browser, why do we need these details? How will it help? All we need to know is that a cookie with a given ID is tied to a particular computer. I don't want to include detail in the report unless it is really useful.

However, the report does mention how many times a user has been allocated a cookie, and warns if this number is too high - could indicate cookie deleting behaviour. However, users who delete their cookies after each session will probably never be caught by this hack anyway.

Originally Posted by nocte

The first save date of the cookie should be reported.

Yes, the first time each user is added to a cookie this date is saved both in the cookie and in the DB. It is also mentioned in any reports.

Originally Posted by nocte

I'd love to have a automatic cronjob that searched once a day for users who were during the last 24 hours online with the same ip-adress. We have a very huge forum that is a few years old so searching for a specific ip often shows dozens of users who accidently had the ip-adress during the last years.

Such a feature is out of scope for this mod and has nothing to do with any of its functions. However, you should be able to do this with a simple SQL query, or write such a cronjob yourself. Remember that people who work in the same company would be flagged with this. Most of my users are in the same country, so such a report would produce so many false positives that it would keep me busy investigating them all!!

I'll post some samples a bit later on about how some of the reports look that are running on my forum at the moment.

[Darat]

AED - I've always thought it stood for "alter ego detector".

[mfyvie]

Ok everyone - it's time to show you some goodies of how this product looks so far. As I said earlier only the backend is done (a few minor tweaks to do), but you can see a few things in the meantime.

The program is keeping a running log. This is basically a development feature I put in to track how the flow of the program through the various bits. But actually it turned out kind of cool.

This is what the standard text looks like for an alert message raised to the admins:

(note that I have removed personal info like email address)

Duplicate Account Alert

Multiple users have been detected using the same computer. The following details are available:

Unique cookie ID: 241
Date cookie dropped: 10:38, 24th Jun 2007
Cookie first dropped for: Francko

Manage or configure options for this computer(cookie) here or for all cookies here.

User Details

Username (ID): Francko (4353)

First seen on this cookie: 10:38, 24th Jun 2007
Last seen on this cookie: 10:38, 24th Jun 2007
Cookies used last 720 days: 2
Cookies used last 30 days: 2
Joined date: 02:06, 17th Apr 2007
Last activity: 02:40, 23rd Jun 2007
Number of posts: 1
Email address: ****@hotmail.com
Ban status: Not banned (Ban this user)

The following profile information is recorded for this user - Location: -

---

Username (ID): Egla (4630)

First seen on this cookie: Imported from legacy cookie
Last seen on this cookie: Imported from legacy cookie
Cookies used last 720 days: 0
Cookies used last 30 days: 0
Joined date: 22:56, 24th Apr 2007
Last activity: 13:46, 19th Jun 2007
Number of posts: 14
Email address: ****@yahoo.co.uk
Ban status: Not banned (Ban this user)

The following profile information is recorded for this user - Location: London

---

This report was generated by a modification for vBulletin that detects multiple users using the same computer. Details for this modification can be found here.

The users can also get a PM. This is what they look like on my system, but the standard version of the product will have different, more generic text:

Dear test03,

We've recently had reason to believe that either someone else has been using your account, or that you may have two accounts on this system.

Sometimes we make mistakes, so we'd just like to check whether you are using more than one account. Please take a moment to read through this information, which outlines our policy.

It may explain why we have sent you this message.

We'd be grateful if you could clarify this situation for us. Please note: If we do not hear from you in 7 days, or by 29.06.2007, your account will be automatically banned. If this is an honest misunderstanding, please accept our apologies in advance

Thanks for your understanding and co-operation in this matter.

I've still got a few minor tweaks like adding info to the admin reports that a user will get a PM and whether or not they will be banned or suspended, and how much time they have left.

Please also see screenshot attached to this post.

[nocte]

Originally Posted by mfyvie

I have deliberately left out IP address and browser info from the reporting. Why? IP address is becoming more and more useless as a way to track users - that's the whole idea behind the cookie-based approach. Many users are logging on via proxies (for example when they are at work), or are using dynamically allocated address which are changing often. Including the IP really would be of limited use.

Imagine this situation (we accutally have this issue):

There?s a Club with a public internet terminal. Many forum users log in there.

The Club?s owner has an account too as well as many more fake accounts to promote his club.

Sometimes the owner uses his own PC ? so we can be quite sure that in that case all multiple accounts are fake accounts.

Sometimes the owner uses the public PC ? in that case we can?t distinguish between normal users and the owner?s fake accounts.

So let?s imagine the owner clears the browser cache on his private computer and logs in again with several of his accounts. In this case we have to wait and watch again for a while till we can guess whether he?s using the public or the private PC (in other words: if we can ban all multiple accounts or if there may be normal users among them)

Did I make myself clear? When public computers are involved it may be very comfortable to have system data as well.

[NeitherSparky]

Originally Posted by mfyvie

Please also see screenshot attached to this post.

I'm NeitherSparky and I approve this mod. Looks great!

[Bravo]

Originally Posted by mfyvie

Ok everyone - it's time to show you some goodies of how this product looks so far. As I said earlier only the backend is done (a few minor tweaks to do), but you can see a few things in the meantime.

The program is keeping a running log. This is basically a development feature I put in to track how the flow of the program through the various bits. But actually it turned out kind of cool.

This is what the standard text looks like for an alert message raised to the admins:

(note that I have removed personal info like email address)

The users can also get a PM. This is what they look like on my system, but the standard version of the product will have different, more generic text:

I've still got a few minor tweaks like adding info to the admin reports that a user will get a PM and whether or not they will be banned or suspended, and how much time they have left.

Please also see screenshot attached to this post.

do you have a beta for this that can be used?
looks awesome nice job so far