[support] How to safeguard sites from unwanted users

Jamie Holly hovercrafter at earthlink.net
Fri Jun 21 14:49:27 UTC 2013


Why go through all that? You're reinventing the wheel. Just block the 
unwanted users and then a new user can not be created with the same name.

Also consider that a vast majority of spammers use a program to randomly 
generate a user name. That means that their are huge odds of them never 
using the same name twice for registration.

Jamie Holly
http://www.intoxination.net
http://www.hollyit.net

On 6/21/2013 10:15 AM, Kamal Palei wrote:
> I am thinking of below solution.
>
> For my site, it is easy for us to find who are unwanted users using 
> some mechanism. I am planning to write a custom module, that will 
> allow administrator to list down unwanted users and these users 
> references I will keep in a separate table , lets call it *table-a*. 
> When a new user registers, I will check table-a, and if any entry 
> found, I will use that entry's UID, for new user. Thereby over the 
> time, anytime you see the unwanted users in my site will be less.
>
> Best Regards
> Kamal
> Net Cloud Systems, Bangalore-08
>
>
> On Fri, Jun 21, 2013 at 7:30 PM, Jamie Holly 
> <hovercrafter at earthlink.net <mailto:hovercrafter at earthlink.net>> wrote:
>
>     The goal is to make it more difficult for people to register unwanted
>     accounts. You aren't going to stop it completely. Email
>     verification is
>     just another hoop for them to jump through, one that is also
>     accepted by
>     a vast majority of regular users. It should always be used.
>
>     Something I did for a client last year was a custom module. It did
>     a few
>     things. First we could set the number of registrations per IP in a
>     given
>     time frame. After that the account requires admin approval. It also
>     recorded all the request headers so that I could look for a pattern,
>     which I ended up finding. Once I was able to isolate that, I blocked
>     that pattern from registering, which took a client's site from a few
>     hundred spam registrations per day, down to one or two per week.
>     Per my
>     agreement with that client, I can't give out that pattern, but doing
>     something similar on any site wouldn't be that complex.
>
>     A common practice now is for companies to hire people to generate
>     these
>     accounts. They then use the accounts to spam your site. After that a
>     company contacts you regarding the spam on your site, offering to
>     "clean
>     it up" and help your seo rankings. Very, very dirty indeed.
>
>     The interesting part of that is what we found out. The registrations
>     were happening from IP addresses all around the globe, yet the actual
>     spam postings were mostly from U.S. IP addresses and over 70% were
>     from
>     hosting companies that offer VPS. We were successful in getting one
>     hosting company to shut down an account, but most just ignore it.
>
>     The whole morale of the story is vigilance. Things like CAPTCHA, email
>     verification and keeping bad user accounts to prevent reuse of bad
>     names
>     and emails all give an extra layer of security (albeit not all that
>     much). Or do you believe in leaving the front door of your home
>     standing
>     wide open, when you aren't there?
>
>
>     Jamie Holly
>     http://www.intoxination.net
>     http://www.hollyit.net
>
>     On 6/21/2013 1:56 AM, John Summerfield wrote:
>     > On 12/06/2013 10:37 PM, Jamie Holly wrote:
>     > > +1 to that! Also, they can't reuse the email. Make it harder
>     on them,
>     > > not easier.
>     >
>     > Reread gmail's rules about its email addresses. One can generate any
>     > number of alternatives for any one email address. Besides,
>     unless one
>     > requires email addresses to be verified during registration,
>     users can
>     > use anything at all, even fred at example.net
>     <mailto:fred at example.net> or joe at domain.test (both of
>     > which _can_ be valid).
>     >
>     > Email hosts often allow +arbitrarySuffix to the localpart of email
>     > addresses, but the "+" can be another arbitrary character, I've seen
>     > hyphens used.
>     >
>     > And then there are some domains where everything is delivered,
>     if not to
>     > a specific addressee then to a default address and that too is
>     configurable.
>     >
>     >
>     >
>     >
>
>     --
>     [ Drupal support list | http://lists.drupal.org/ ]
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20130621/41e08d76/attachment-0001.html 


More information about the support mailing list