How to safeguard sites from unwanted users
Dear ALL I see almost everyday in my site 2 or 3 unwanted users are created. The user id is something like *sdfdxsxvxcvbcxmv* which is totally somebody just playing. I need to block such accounts or more preferably reuse such accounts. For me the concern is , once a user is created, that user id is gone for ever. Next if I create another user, it will take up the higher UID. Assuming these things keeps happening, over few years of time we will have lot of unnecessary accounts in system, eating up resources for nothing. Even if I delete these users, still the user ID will not be reused. Within Drupal framework, is there any existing mechanism where, we can tell to re-use certain user ID when creating new users. If NOT existing, if somebody guides me, am ready to make one. Best Regards Kamal
I've used the spambot module and it helped but it can't stop all unwanted registrations. Tracey -------------------- Tracey Hummel Web Application Developer tracey@arizona.edu http://tshummel.com ________________________________ From: support-bounces@drupal.org [support-bounces@drupal.org] on behalf of Kamal Palei [palei.kamal@gmail.com] Sent: Tuesday, June 11, 2013 4:22 AM To: support@drupal.org Subject: [support] How to safeguard sites from unwanted users Dear ALL I see almost everyday in my site 2 or 3 unwanted users are created. The user id is something like sdfdxsxvxcvbcxmv which is totally somebody just playing. I need to block such accounts or more preferably reuse such accounts. For me the concern is , once a user is created, that user id is gone for ever. Next if I create another user, it will take up the higher UID. Assuming these things keeps happening, over few years of time we will have lot of unnecessary accounts in system, eating up resources for nothing. Even if I delete these users, still the user ID will not be reused. Within Drupal framework, is there any existing mechanism where, we can tell to re-use certain user ID when creating new users. If NOT existing, if somebody guides me, am ready to make one. Best Regards Kamal
Tracey Thanks a lot. Probably spambot will guard against spam users registration to some extent. If somehow, some spam users register in site (we can determine manually or automated way), I would like to re-use the UID allocated for spam users should be re-used for future valid users. In that case, do we have any modules or any existing mechanism to achieve re-using the UIDs allocated to spam users previously. Thanks kamal On Tue, Jun 11, 2013 at 8:19 PM, Hummel, Tracey S - (thummel) < thummel@email.arizona.edu> wrote:
I've used the spambot module and it helped but it can't stop all unwanted registrations.
Tracey
-------------------- Tracey Hummel *Web Application Developer* tracey@arizona.edu http://tshummel.com ------------------------------ *From:* support-bounces@drupal.org [support-bounces@drupal.org] on behalf of Kamal Palei [palei.kamal@gmail.com] *Sent:* Tuesday, June 11, 2013 4:22 AM *To:* support@drupal.org *Subject:* [support] How to safeguard sites from unwanted users
Dear ALL I see almost everyday in my site 2 or 3 unwanted users are created. The user id is something like *sdfdxsxvxcvbcxmv* which is totally somebody just playing. I need to block such accounts or more preferably reuse such accounts.
For me the concern is , once a user is created, that user id is gone for ever. Next if I create another user, it will take up the higher UID.
Assuming these things keeps happening, over few years of time we will have lot of unnecessary accounts in system, eating up resources for nothing.
Even if I delete these users, still the user ID will not be reused.
Within Drupal framework, is there any existing mechanism where, we can tell to re-use certain user ID when creating new users. If NOT existing, if somebody guides me, am ready to make one.
Best Regards Kamal
-- [ Drupal support list | http://lists.drupal.org/ ]
On 6/12/13 12:46 AM, Kamal Palei wrote:
Tracey Thanks a lot. Probably spambot will guard against spam users registration to some extent.
If somehow, some spam users register in site (we can determine manually or automated way), I would like to re-use the UID allocated for spam users should be re-used for future valid users. In that case, do we have any modules or any existing mechanism to achieve re-using the UIDs allocated to spam users previously.
Thanks kamal
On Tue, Jun 11, 2013 at 8:19 PM, Hummel, Tracey S - (thummel) <thummel@email.arizona.edu <mailto:thummel@email.arizona.edu>> wrote:
I've used the spambot module and it helped but it can't stop all unwanted registrations.
Tracey
-------------------- Tracey Hummel /Web Application Developer/ tracey@arizona.edu <mailto:tracey@arizona.edu> http://tshummel.com ------------------------------------------------------------------------ *From:* support-bounces@drupal.org <mailto:support-bounces@drupal.org> [support-bounces@drupal.org <mailto:support-bounces@drupal.org>] on behalf of Kamal Palei [palei.kamal@gmail.com <mailto:palei.kamal@gmail.com>] *Sent:* Tuesday, June 11, 2013 4:22 AM *To:* support@drupal.org <mailto:support@drupal.org> *Subject:* [support] How to safeguard sites from unwanted users
Dear ALL I see almost everyday in my site 2 or 3 unwanted users are created. The user id is something like *sdfdxsxvxcvbcxmv* which is totally somebody just playing. I need to block such accounts or more preferably reuse such accounts.
For me the concern is , once a user is created, that user id is gone for ever. Next if I create another user, it will take up the higher UID.
Assuming these things keeps happening, over few years of time we will have lot of unnecessary accounts in system, eating up resources for nothing.
Even if I delete these users, still the user ID will not be reused.
Within Drupal framework, is there any existing mechanism where, we can tell to re-use certain user ID when creating new users. If NOT existing, if somebody guides me, am ready to make one.
Best Regards Kamal
Why are you worried about loss of a few UID's, the table? You can have about 4 BILLION different UID's, if you are worried about using up all your UIDs you site must be EXTREMELY active, and there are a number of other things that need to be looked at well before you run out of UIDs. (and a relatively small change in table schema can increase the limit to virtually unlimited by changing UID to a bigint everywhere it is stored). -- Richard Damon
On Wed, Jun 12, 2013 at 12:46 AM, Kamal Palei wrote:
Tracey Thanks a lot. Probably spambot will guard against spam users registration to some extent.
If somehow, some spam users register in site (we can determine manually or automated way), I would like to re-use the UID allocated for spam users should be re-used for future valid users. In that case, do we have any modules or any existing mechanism to achieve re-using the UIDs allocated to spam users previously.
You want to block and not delete those SPAM users so they cannot use the same user name for the SPAM. At least that is my take on life on the internet. -- Earnie -- https://sites.google.com/site/earnieboyd
+1 to that! Also, they can't reuse the email. Make it harder on them, not easier. Dealing with spam is always a pain. You need to balance out trying to prevent spam accounts with not complicating your user experience. Simple rule: the more hoops a user has to jump through to register, the less likely they are to register. The big problem today is that there are people actually being paid to register spam accounts. One of the big culprits are these fly by night companies offering SEO help. They pay some foreign company to register accounts and spam sites, then they contact the site saying "HEY! We can help get your SEO ranking up". Of course that's after it was after their actions caused it to go down. It's a dirty practice, but one that does exist today and is continuing to grow. Basically you aren't going to stop it. If you do, then sell your plan and watch Microsoft, Google, Yahoo and others pay you big bucks for it, especially when you consider the emails they are using are usually from one of those providers. Just keep on it, blocking the accounts as they pop up and eventually it will die off. Vigilance is the best tool to combat spam. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 6/12/2013 9:55 AM, Earnie Boyd wrote:
On Wed, Jun 12, 2013 at 12:46 AM, Kamal Palei wrote:
Tracey Thanks a lot. Probably spambot will guard against spam users registration to some extent.
If somehow, some spam users register in site (we can determine manually or automated way), I would like to re-use the UID allocated for spam users should be re-used for future valid users. In that case, do we have any modules or any existing mechanism to achieve re-using the UIDs allocated to spam users previously.
You want to block and not delete those SPAM users so they cannot use the same user name for the SPAM. At least that is my take on life on the internet.
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@example.net or joe@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. -- Cheers John
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@example.net or joe@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.
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@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@example.net or joe@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/ ]
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@earthlink.net <mailto:hovercrafter@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@example.net <mailto:fred@example.net> or joe@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/ ]
Hi Jamie True, but I just took a look at last 7 days data. For my site, new valid users 2 , and junk users are around 10. So in this rate if it goes, i will have more junk users than valid users. The only option that comes to my mind is, re-use the junk user space for new users (again it may be valid or junk user). But in the process always we will have less junk users. However I will do once I finish number of pending tasks. Best Regards Kamal Net Cloud Systems Bangalore-08 On Fri, Jun 21, 2013 at 8:19 PM, Jamie Holly <hovercrafter@earthlink.net>wrote:
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 Hollyhttp://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@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@example.net or joe@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/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
The problem you will still encounter is the random user names. I've got a list from one client of over 17,000 spam names that are random, and that's from about a 4 month period. IMHO the better option would be to just block them, then write a small module to run on cron and delete the blocked users more than X days old, if the names in the user table is of concern. Another option. With only 2 valid users in a week, set the site to where an admin has to validate an account. Let that run for a couple of weeks and there's a good chance the person spamming you will give up. After that, go ahead and open it back up. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 6/22/2013 12:36 AM, Kamal Palei wrote:
Hi Jamie True, but I just took a look at last 7 days data. For my site, new valid users 2 , and junk users are around 10. So in this rate if it goes, i will have more junk users than valid users.
The only option that comes to my mind is, re-use the junk user space for new users (again it may be valid or junk user). But in the process always we will have less junk users.
However I will do once I finish number of pending tasks.
Best Regards Kamal Net Cloud Systems Bangalore-08
On Fri, Jun 21, 2013 at 8:19 PM, Jamie Holly <hovercrafter@earthlink.net <mailto:hovercrafter@earthlink.net>> wrote:
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@earthlink.net <mailto:hovercrafter@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@example.net <mailto:fred@example.net> or joe@domain.test <mailto:joe@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/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
Another option, depending on use case, I manage a Drupal site for an Open Source community and I don't even care about the users. The users may register without admin approval but if they wish to add to the wiki they must request access to post on the groups support list. I then just add a role giving them permission to post. I went from many spam to zero in a matter of one day once I implemented that policy. Kamal, you may be interested in https://drupal.org/project/user_verify; I haven't tried it but it should help with lowering the SPAM user registration. The idea is a good one. Earnie On Sat, Jun 22, 2013 at 1:08 AM, Jamie Holly wrote:
The problem you will still encounter is the random user names. I've got a list from one client of over 17,000 spam names that are random, and that's from about a 4 month period.
IMHO the better option would be to just block them, then write a small module to run on cron and delete the blocked users more than X days old, if the names in the user table is of concern.
Another option. With only 2 valid users in a week, set the site to where an admin has to validate an account. Let that run for a couple of weeks and there's a good chance the person spamming you will give up. After that, go ahead and open it back up.
Jamie Holly http://www.intoxination.net http://www.hollyit.net
On 6/22/2013 12:36 AM, Kamal Palei wrote:
Hi Jamie True, but I just took a look at last 7 days data. For my site, new valid users 2 , and junk users are around 10. So in this rate if it goes, i will have more junk users than valid users.
The only option that comes to my mind is, re-use the junk user space for new users (again it may be valid or junk user). But in the process always we will have less junk users.
However I will do once I finish number of pending tasks.
Best Regards Kamal Net Cloud Systems Bangalore-08
On Fri, Jun 21, 2013 at 8:19 PM, Jamie Holly <hovercrafter@earthlink.net> wrote:
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@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@example.net or joe@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/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Earnie -- https://sites.google.com/site/earnieboyd
On 12/06/2013 9:55 PM, Earnie Boyd wrote:
You want to block and not delete those SPAM users so they cannot use the same user name for the SPAM. At least that is my take on life on the internet.
Does nothing. A name is easily chosen, I could as easily use "erniebboyd+" . $I++ to create a nee name (and "different" email address while I'm at it) gmail email addresses are easily obscured. -- Cheers John
On 11/06/2013 7:22 PM, Kamal Palei wrote:
For me the concern is , once a user is created, that user id is gone for ever. Next if I create another user, it will take up the higher UID.
The consequences of this are negligible. All UIDs in my table are of the "bigint" kind. The storage requirement for any number from 0 to 2^63 is the same, larger values require no more storage than smaller ones. The problems are deleting the unwelcome guests and any data they have left, that's a chore, and approving those who are welcome and that too is a chore. For my purposes, I have decreed that at Mandurah Chess they must be located in Australia to register. I use the ip2country module's data (note that ip2country has problems which in my opinion make it unsuitable for general use) for a custom module that enforces this. It could as well blacklist countries or be extended to use a table containing blacklist and/or whitelisted countries. It would be of limited use in China or Russia, but it seems Australians are a well-behaved lot. I personally dislike capchas and am very likely to not bother you at all, even it it's to your benefit. -- Cheers John
participants (6)
-
Earnie Boyd -
Hummel, Tracey S - (thummel) -
Jamie Holly -
John Summerfield -
Kamal Palei -
Richard Damon