Prevent spammers from registering

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

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.

[Steffen Hoffmann]

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. ;-)

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

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

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

[anonymous]

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

[Steffen Hoffmann]

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

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

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

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

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

[Dirk Stöcker]

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.

[Steffen Hoffmann]

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.

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

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

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

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

[Steffen Hoffmann]

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

[Steffen Hoffmann]

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

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