Ticket #7577 (new enhancement)

Opened 1 year ago

Last modified 7 months ago

Prevent spammers from registering

Reported by: anonymous Assigned to: 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

Change History

(in reply to: ↑ description ) 10/04/10 20:56:38 changed by hasienda

  • keywords set to needinfo SPAM register prevention.
  • 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. ;-)

(follow-up: ↓ 3 ) 01/03/11 01:00:35 changed 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.

(in reply to: ↑ 2 ) 01/03/11 01:31:04 changed 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.

01/03/11 20:14:49 changed 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.

06/17/11 17:20:11 changed by anonymous

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

06/28/11 23:20:56 changed by hasienda

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

07/13/11 18:02:25 changed 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.


Add/Change #7577 (Prevent spammers from registering)




Change Properties
Action