Modify

Opened 14 years ago

Closed 12 years ago

Last modified 12 years ago

#7577 closed enhancement (fixed)

Prevent spammers from registering

Reported by: anonymous Owned by: Steffen Hoffmann
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 14 years ago by Steffen Hoffmann

Keywords: needinfo SPAM register prevention added
Owner: changed from John Hampton to Steffen Hoffmann
Type: defectenhancement

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 Changed 14 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 14 years ago by Steffen Hoffmann

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 14 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 13 years ago by anonymous

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

comment:6 Changed 13 years ago by Steffen Hoffmann

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

comment:7 Changed 13 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 12 years ago by Steffen Hoffmann

(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 12 years ago by Steffen Hoffmann

(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 12 years ago by Steffen Hoffmann

(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 Changed 12 years ago by Dirk Stöcker

Resolution: fixed
Status: newclosed

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 12 years ago by Steffen Hoffmann

Resolution: fixed
Status: closedreopened

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 12 years ago by Steffen Hoffmann

(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 12 years ago by Steffen Hoffmann

(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 12 years ago by Dirk Stöcker

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 12 years ago by Steffen Hoffmann

(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 12 years ago by Steffen Hoffmann

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

comment:18 Changed 12 years ago by Steffen Hoffmann

Resolution: fixed
Status: reopenedclosed

(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 12 years ago by Steffen Hoffmann

(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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Steffen Hoffmann.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


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

 
Note: See TracTickets for help on using tickets.