View Issue Details

IDProjectCategoryView StatusLast Update
0021028mantisbtadministrationpublic2016-07-19 15:59
Reporterdregad Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionopen 
Summary0021028: Loosen or remove antispam limit based on user seniority
Description

As discussed by e-mail following recent wave of spam attacks.

We should implement logic that improves our antispam protection, without negatively affecting "good" users.

One possibility would be to give some kind of "rating" to users, based on how long ago they registered, and/or how many issues / comments they posted. The rule to calculate this rating is to be discussed.

We could then use this rating to have differentiated antispam behavior, e.g. if it's high enough:

  • reduce or remove antispam post rate limit
  • allow specific, restricted actions (e.g. use mass-update functions in view issues page)
TagsNo tags attached.

Activities

atrol

atrol

2016-07-18 17:55

developer   ~0053637

Last edited: 2016-07-18 17:55

Some thoughts to start discussion

New
function get_user_reputation() {
$t_reptutation = 3 number_of_created_issues + 1 number_of_added_notes;

Don't count issues and notes that have been created the last n days.

# This is to exclude the latest spam that might have found it's way into the system. 
# 2 days could be the default.
# e.g. set to 1 day for projects where administrator is watching on a daily basis.
# set to 7 days for projects where administrator is able to check just on time a week.

}

Change
function antispam_check() {

if( access_get_global_level() > config_get( 'default_new_account_access_level' ) ) {
    return;
}

$t_antispam_max_event_count = get_user_reputation();

# Make sure user has at least one more event to add before exceeding the limit, which will happen
# after this method returns.
$t_antispam_time_window_in_seconds = config_get( 'antispam_time_window_in_seconds' );
if( history_count_user_recent_events( $t_antispam_time_window_in_seconds ) < $t_antispam_max_event_count ) {
    return;
}

error_parameters( $t_antispam_max_event_count, $t_antispam_time_window_in_seconds );
trigger_error( ERROR_SPAM_SUSPECTED, ERROR );

}

vboctor

vboctor

2016-07-18 22:55

manager   ~0053639

@atrol the concept makes sense. But doesn't get_user_reputation() return 0 for new users, hence, they can't add any issues or notes to start with?

atrol

atrol

2016-07-19 02:33

developer   ~0053640

they can't add any issues or notes to start with?
Yes, that's the most secure way to avoid spam.

Joking aside, I got aware of it when going to bed, but too late to correct it.

We could add config_get( 'antispam_max_event_count' ) to the reputation.
After that we could avoid expensive history_count_user_recent_events call if reputation is greater than a certain value (e.g. 2*antispam_max_event_count)

rombert

rombert

2016-07-19 12:46

reporter   ~0053657

How about twisting the logic a bit and marking the issues and comments untrusted users create as private?

Then we could manually 'vet' new users and allow them to create public issues and comments. This of course requires some new admin pages, and maybe a way of making issues that were once private public ... Maybe not the best idea

atrol

atrol

2016-07-19 15:59

developer   ~0053659

This is similar to what I have configured in our forum.
The first posts of new users are not published but go through a so called mederation queue.
Users can post without moderation after two published posts.
If a user wants start spamming, there are just a few clicks to delete the user including all posts.

I am not sure if using "private" for two different things ("private" or "not published") is a good idea.
Maybe unpublished/public/private as possible values would be needed to implement this approach.