Modify

Opened 4 years ago

Closed 21 months ago

Last modified 20 months ago

#7577 closed enhancement (fixed)

Prevent spammers from registering

Reported by: anonymous Owned by: hasienda
Priority: normal Component: AccountManagerPlugin
Severity: normal Keywords: needinfo SPAM register prevention
Cc: Trac Release: 0.11

Description

I get lots of spammers registering user accounts by accident (they want to spam only).

There should be validity checks on input data to prevent this.

Possibilities:
a) Have a field which must be filled with a certain value
b) have a hidden field with email in the name, which MUST not be filled (spam bots usually will fill in an email :-)

It should not be a 100% secure spam prevention, but at least it should reduce unwanted registering.

Attachments (0)

Change History (19)

comment:1 in reply to: ↑ description Changed 4 years ago by hasienda

  • Keywords needinfo SPAM register prevention added
  • Owner changed from pacopablo to hasienda
  • Type changed from defect to enhancement

Replying to anonymous:

I get lots of spammers registering user accounts by accident (they want to spam only).

There should be validity checks on input data to prevent this.

Would you suggest adding captcha support not only to registration form but to other forms as well? Your ticket summary is clear (No) but your description suggest it (Maybe)?

Possibilities:
a) Have a field which must be filled with a certain value

This is captcha (see #2707 and #2897). I wouldn't dare to re-invent the wheel and do anything new now without additional help.

b) have a hidden field with email in the name, which MUST not be filled (spam bots usually will fill in an email :-)

Any reference, where this is already applied?

As you may guess from my questions, I'll decide depending on further input how to proceed with this ticket. Certainly, this is an enhancement, and probably even a duplicate of the aforementioned tickets that both have the big advantage to already be backed up by real code and even positive tester feedback. All that is this ticket lacking until now. With real improvements in mind I'll certainly focus on 1.) urgent and 2.) easily doable things first.

It should not be a 100% secure spam prevention, but at least it should reduce unwanted registering.

Needless to say, there is no such thing like 100%. Anyway let's aim at 0% SPAM then. ;-)

comment:2 follow-up: Changed 4 years ago by anonymous

Regarding captcha - I maintain the SpamFilter plugin and would be happy when instead of own captcha solutions also the AccountManager could use the SpamFilter infrastructure.

SpamFilter has the big advantage, that it only requests a Captcha after the score got high, so normal users wont see the captcha at all. Thought I do not know if there is enough information in account creationg to have a good detection base. Probably user name and e-mail is not enough.

Regarding the hidden e-mail. We have a contact form, with normal input field "E-Mail" in text and mail in name and a similar second field, but in a table with css style "dis_play:none;" (without the "_", as improper configured SpamFilter of trac-hacks.org prevents sending of correct text). Normal users don't see it, but every spammer fills in the second e-mail :-) Thought they will adapt over the time.

comment:3 in reply to: ↑ 2 Changed 4 years ago by hasienda

Replying to anonymous:

Regarding captcha - I maintain the SpamFilter plugin and would be happy when instead of own captcha solutions also the AccountManager could use the SpamFilter infrastructure.

Ah, well then you're not that anonymous anymore, Dirk.

SpamFilter has the big advantage, that it only requests a Captcha after the score got high, so normal users wont see the captcha at all. Thought I do not know if there is enough information in account creationg to have a good detection base. Probably user name and e-mail is not enough.

That has been my immediate thought too, so maybe not much Bayes, but maybe we could still make use of IP-based filtering and other goodies?

I have to admit, I barely no anything about the SpamFilterPlugin until now. As with other plugins most probably I'll have to dig into the source, right?

Regarding the hidden e-mail. We have a contact form, with normal input field "E-Mail" in text and mail in name and a similar second field, but in a table with css style "dis_play:none;" (without the "_", as improper configured SpamFilter of trac-hacks.org prevents sending of correct text). Normal users don't see it, but every spammer fills in the second e-mail :-) Thought they will adapt over the time.

I hate SPAM, but I hate to spend much time on countermeasures too, that need constant/regular adustment to prevent/react on adoption from the other side. So I tend to doing the best, not the easiest/quickest thing first.

comment:4 Changed 4 years ago by anonymous

Well, yes, SpamFilter will allow to use all the methods, but most effective are Akismet, TypePad and Bayes filter (the first two probably using something like Bayes filtering as well). Akismet and TypePad use also HTTP header inspection, so I assume usage of SpamFilter would help for AccountManger. I already thought about adding headers to internal Bayes tests as well.

What we need to integrate this is mainly an adapter like these http://trac.edgewall.org/browser/plugins/0.12/spam-filter-captcha/tracspamfilter/adapters.py and the relevant interface to call the adapter in AccountManager. I think the rest of the infrastructure is already there. I'm not a Trac guru, so maybe there already are necessary interfaces and we only need to use these.

Actually I think using the plugin is better than own solutions, as the plugin has now a pretty good infrastructure and can thus be a central point of fighting against SPAM. Every news in that area would then be usable in other areas as well.

I'm happy to accept patches for basic integration (and BTW am happy to see coming AccountManager to life again :-) I would do fine tuning then to get good performance.

comment:5 Changed 3 years ago by anonymous

A proper interface seems to be http://trac-hacks.org/wiki/RegistrationConfirmationPatch, see also #2897.

comment:6 Changed 3 years ago by hasienda

Sure, that's why I've already reference it over there. But thanks for the reminder here too.

comment:7 Changed 3 years ago by anonymous

One more idea would be to have a blacklist for user names. I often see specific strings in there against which could be checked, like "c_asino" or "i_nsurance" (no underscores, they are just for posting here). Preferably this list is stored in some plain text file on disk with configurable location, so the same content can be used for multiple trac environments.

comment:8 Changed 2 years ago by hasienda

(In [11917]) AccountManagerPlugin: Add interface for configurable user registration procedure, refs #874, #2707, #2897, #4651, #5295, #7577, #8076.

The current user registration process lacks flexibility, as can be witnessed by
the history of one of the oldest still pending tickets for this plugin: #874.

comment:9 Changed 2 years ago by hasienda

(In [11923]) AccountManagerPlugin: Finish registration check rewrite, refs #874, #2707, #2897, #4651, #5295, #7577, #8076.

Now moving check execution into AccountManager, and _create_user() is gone,
replaced by more clearly structured and modularized code.

Registration checking for requests from the admin panel is re-activated and
minor improvements related to RegistrationError processing done too.

Note: The test, that detected admin requests to skip additional checking of
existing permissions for each new username, has been done differently.
In the future each check has to decide on its own, like this is done in the
UsernamePermCheck now.

comment:10 Changed 2 years ago by hasienda

(In [12048]) AccountManagerPlugin: Add some simple registration checks for fighting bots, refs #874 and #7577.

There is a mandatory field with required input provided as hint below.
The field is only visible and the check working after you've assigned a value
to the new option register_basic_token.

"Plan B" in the list of suggested improvements for new user registration is
a hidden input field, that might get only ever filled by bot clients.
Unlike the other one above this check always works - without configuration.

comment:11 follow-up: Changed 2 years ago by stoecker

  • Resolution set to fixed
  • Status changed from new to closed

SpamFilter now can plug into accountmanager, which allows to close that ticket. And BTW after a bit training the bayes filter catches lot of spam registrations, but not all :-(

If someone has a good idea how to convince spammers to be more spammy for registering (so the bayes checks get better), please report a spam-filter ticket at trac.edgewall.org for it.

comment:12 in reply to: ↑ 11 Changed 2 years ago by hasienda

  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to stoecker:

SpamFilter now can plug into accountmanager, ...

Great, thanks for your work. I'll add a reference to the registration part of the wiki documentation for this plugin.

I prefer to close tickets only after/on release, so please don't close this one on behalf of mine as well.

comment:13 Changed 23 months ago by hasienda

(In [12135]) AccountManagerPlugin: Defer registration error message translation, refs #7577.

This enables capturing untranslated messages i.e. for logging.
And msgid's have been cleaned from excessive whitespace and line breaks.
Thanks to Dirk Stöcker for providing inspiring test feedback for these changes.

comment:14 Changed 23 months ago by hasienda

(In [12137]) AccountManagerPlugin: Just noticed, that [12135] disabled translation for one msgid, refs #7577.

Deferred translation can't be done for composed strings like this one.

comment:15 Changed 22 months ago by stoecker

The last should be correct like: N_("The username must not contain any of these characters: %s). If not, then dropping the tag.p and simply adding texts directly should work.

comment:16 Changed 22 months ago by hasienda

(In [12384]) AccountManagerPlugin: Follow-up to [12137] with a modified error class, refs #7577, #9052 and #9090.

The new RegistrationError class definition requires minor changes to
existing IAccountRegistrationInspector implementations, but I couldn't find
an easier way to preserve additional arguments for string substition until
after deferred message string translation.

I've done changes in all message catalogs accounting for the tiny msgid change
right-away to obsolete further action by individual translators.

Finally I'm registering resolution for two more tickets after testing account
change notification with a more recent AnnouncerPlugin version successfully.

comment:17 Changed 22 months ago by hasienda

(In [12385]) AccountManagerPlugin: Add import missing from admin code after [12384], refs #7577, #9052, #9090 and #9940.

comment:18 Changed 21 months ago by hasienda

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [12398]) AccountManagerPlugin: Releasing version 0.4, pushing development to acct_mgr-0.5dev.

Availability of that code as stable release
closes #874, #3459, #4677, #5295, #5691, #6616, #7577, #8076, #8685, #8770, #8791, #8990, #9052, #9079, #9090, #9139, #9246, #9252, #9547, #9618, #9676, #9843, #9852, #9940, #10023, #10028, #10123, #10142, #10204, #10276, #10397, #10412, #10594, #10625 and #10644.

Some more issues have been worked-on, yet without confirmed resolution,
refs #5464 (for JiraToTracIntegration), #8927 and #10134.

And finally there are some issues and enhancement requests showing progress,
but known to require more work to resolve them satisfactorily,
refs #843, #1600, #5964, #8217, #8933.

Thanks to all contributors and followers, that enabled and encouraged a good
portion of this development work.

comment:19 Changed 20 months ago by hasienda

(In [12491]) AccountManagerPlugin: Skip BotTrapCheck for admin users, refs #7577 and #10681.

Otherwise admin users couldn't create new user accounts with this check
enabled for the new user registration procedure.
Background: There's no way to pass that check there, because the hidden field
isn't supplied to user admin panel, but to the registration form exclusively.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.