prevent password (account) sharing

[Ruth]

Anyone?

[VirtueTech]

This hack would be very very useful.

I too would implement this on my boards in a heart beat.

[dabean]

You could achieve (a) by firstly modifying the session table to contain a field called “active”. Then with the new field added it becomes as simple as setting active to 1 every time a new session is created and most importantly setting “active” of all other sessions for that userid that have a different IP address to 0. e.g. (UPDATE session SET active =0 WHERE userid=’$bbuserinfo[userid]’ AND host!=’$REMOTE_ADDR’)

Now for the really clever part when a user requests anything you just check to see if the session they are using has been deactivated, if it’s been deactivated you’ve caught simultaneous browsing from different IP addresses.

To achieve (b) Create two new tables (master/detail relationship) called say abuseevent and abusedetail. The reason for using a master detail relationship is it allows for any number of simultaneous sessions.
In abuseevent record the actual abuse e.g. userid, time & abuseid (auto increment)
In abusedetail record each of the IP addresses that where active at the time e.g. abuseid, IP address & abusedetailid (auto increment)

I’ll leave part (c) for someone else to figure out as the solution is extremely involved, personally I would write the code necessary to do parts (a), (b) before even thinking about all extra logic needed for part (c).

[Ruth]

Thanks for your reply dabean,

i like your theory, but due to the fact that i lack complete knowledge about php, i am unable to decide how to modify tables, and what templates and php files to change.

About part (c) , there is an already made hack about mass delete users (made by Blue2000) and can be found at

http://www.vbulletin.com/forum/showt...5&pagenumber=1

i asked for these option to be added

i am wondering if someone canm add these 2 options to this hack:

(1) instead of deleting users, you may have the option to transfer them to another group (say inactive users)

(2) Delete users that have a number of IPs/day, for example if someone has 30 ips/day, the account is more liklely to be a bused, therfore it can delete the account.

which would be easier i think to add the option (C)

so the theory is there for the script, only professional coders needed now

please coders support this script by sharing your codes, and those who are not coders, support the script by saying that you want this script so bad

cheers,

[VirtueTech]

Originally posted by Ruth
(1) instead of deleting users, you may have the option to transfer them to another group (say inactive users)

Kier made this hack to mass move users in and out of usergroups:
http://www.vbulletin.com/forum/showt...threadid=13687

[MattR]

Would you have to enter annother column? I would think something like this:

every time a page is requested:

SELECT count( * ) AS number
FROM session
WHERE userid = $bbuserinfo[userid]
     and lastvisit > $browsertimeout

if( $result[ number ] > 1 ) {
  update user set usergroupid = some_id_for_dup_user_acct
  where userid = $bbuserinfo[ userid ]
}

this would then block the account and at the end of the day you could look at the users in that account, perform reporting, etc.

Or if you wanted to be tricky, you could alter the UPDATE SESSION query to ignore IP and just user USERID..
UPDATE session SET blah
WHERE userid = $bbuserid[ userid ]

then check mysql_num_rows_affected (or whatever the function is). If it updates more than one row, you have two userids in there.

[Ruth]

Cool Ideas ...

someone told me that it is better and easier to use SSI (Server Side Includes) to prevent password sharing

tell me what you think?

[Wayne Luke]

Originally posted by Ruth
Cool Ideas ...

someone told me that it is better and easier to use SSI (Server Side Includes) to prevent password sharing

tell me what you think?

Except that you can't use SSI on dynamically generated pages used in PHP. At least not easily. Since you already have dynamic programmatically generated pages why bother introducing another layer of unneeded complexity?

[Ruth]

Except that you can't use SSI on dynamically generated pages used in PHP. At least not easily. Since you already have dynamic programmatically generated pages why bother introducing another layer of unneeded complexity?

wluke, i guess you are right, i didn't mention that i'm using php with this.

PHP Code:

SELECT count( * ) AS number
FROM session
WHERE userid = $bbuserinfo[userid]
     and lastvisit > $browsertimeout

if( $result[ number ] > 1 ) {
  update user set usergroupid = some_id_for_dup_user_acct
  where userid = $bbuserinfo[ userid ]
} 


MattR
(1) where shall i insert this code? in member.php (start login) and include the member.php in everypage ? or insert it in every page?

(2) how can you look at the blocked account or report it automatically?

Thanks guys

[Wayne Luke]

Member.php really has nothing to do with logging in.. Sure it has an action there to account for it, but that is just to show a template and do the proper redirects.

You could enter it in every file but that is kind of redundant and unmaintainable.

The file you are looking for is session.php. This file handles the logging in of every member whether from form or cookie and more importantly it controls the session table where the information you need is located.

A little pseudo code of how I would do it is:

logging in
check userid
if userid exists in session table
  redirect to error page
  increment invalid login counter.
  max invalid logins reached?
     lock account (flag on user table).
else
  continue with login and proceed.