How to stop fake registrations (lavabit.com accounts)
Locked
12
12
How to stop fake registrations (lavabit.com accounts)
 
|
Hi,
I'm getting a couple of successful fake registrations per week, always from the same 16 bit subnet ("M-net" in Germany) and always by using obviously compromised "lavabit.com" mail accounts. Anyone having the same problem? I have BlackListPlugin with registration protection installed but I am missing a way to block a couple of subnets or registrants using a specific mail provider. Thanks a lot - /Matthias PS: Mail to [hidden email] did not help ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
Am also suffering from lavabit.
Would also like a way to click something in the email to the administrator to handle cases. These would give options to 1) kill this registration
2) block the email domain 3) send a "get lost" email etc. Any ideas? Thanks, Martin
-- [hidden email] http://twitter.com/mrjcleaver +1 416-786-6752 (GMT-5) On Fri, Dec 18, 2009 at 11:05 AM, Matthias Wientapper <[hidden email]> wrote: Hi, ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: Foswiki's registration process is outdated
|
|
On 12/18/09 1:19 PM, Martin Cleaver wrote:
> Am also suffering from lavabit. > > Would also like a way to click something in the email to the > administrator to handle cases. > > These would give options to > 1) kill this registration > 2) block the email domain > 3) send a "get lost" email > > etc. > > Any ideas? > Hi, today started a new wave of bot based registrations, including wiki spam on new user topics. I had to disable user registration. This proves that even with BlackListPlugin and WikiSpamPlugin the currently existing safety measures to prevent bot or script based registrations are not sufficient at all. This might also have negative effect on the reputation of Foswiki with respect to security. IMHO Foswiki's registration procedure is outdated and unsecure. I would like to start a discussion based on what was discussed a year ago on [1] and [2] and that is e.g. using CAPTCHAs [3] to test for humans vs. bots/scripts. This is pretty much a standard for publicly open CMS. Thanks - Best, /Matthias [1] http://foswiki.org/Development/RegistrationTopicHandler [2] http://foswiki.org/Development/PluggableRegistration [3]: http://en.wikipedia.org/wiki/CAPTCHA ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: Foswiki's registration process is outdated
|
|
On 12/20/09 8:00 PM, Matthias Wientapper wrote:
> today started a new wave of bot based registrations, including wiki spam > on new user topics. And obviously I'm not the only victim: http://foswiki.org/Main/ArkwrightBradley http://foswiki.org/Main/MalaBosworth http://foswiki.org/Main/BershBrianna ... Best, /Matthias ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: Foswiki's registration process is outdated
|
In reply to this post by Matthias Wientapper
On Sun, Dec 20, 2009 at 08:00:06PM +0100, Matthias Wientapper wrote:
> I would like to start a discussion based on what was discussed a year > ago on [1] and [2] and that is e.g. using CAPTCHAs [3] to test for > humans vs. bots/scripts. This is pretty much a standard for publicly > open CMS. A while ago I wrote CaptchaPlugin for that other platform (you know, the one with the trademark). That plugin might still work. It provides captcha on user registration. Feel free to port it to Foswiki, I unfortunately do not have the time to spare at the moment :( Gr, Koen > > Thanks - > Best, > /Matthias > > [1] http://foswiki.org/Development/RegistrationTopicHandler > [2] http://foswiki.org/Development/PluggableRegistration > [3]: http://en.wikipedia.org/wiki/CAPTCHA > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Foswiki-discuss mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/foswiki-discuss > > -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: Foswiki's registration process is outdated
|
In reply to this post by Matthias Wientapper
Is it not reasonable to have a plugin that enforces approval of new registrations by a member of AdminGroup before the final registration stuff is done? If this exists, I've not noticed it before.
Cheers. Fil 2009/12/20 Matthias Wientapper <[hidden email]> On 12/18/09 1:19 PM, Martin Cleaver wrote: -- Filippo A. Salustri, Ph.D., P.Eng. Mechanical and Industrial Engineering Ryerson University 350 Victoria St, Toronto, ON M5B 2K3, Canada Tel: 416/979-5000 ext 7749 Fax: 416/979-5265 Email: [hidden email] http://deseng.ryerson.ca/~fil/ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
In reply to this post by Matthias Wientapper
Hi Matthias,
> From: Matthias Wientapper <[hidden email]> ... > I'm getting a couple of successful fake registrations per week, always > from the same 16 bit subnet ("M-net" in Germany) and always by using > obviously compromised "lavabit.com" mail accounts. > > Anyone having the same problem? I am having the same problem also, and it seems these lavabit registrations are just the beginning of a bigger campaign. Where I was getting four registrations per day for the last couple of weeks from @lavabit, today I have 12 registrations: 5x lavabit 4x gmx 1x safe-mail.net 1x @mail.ru 1x legit registration Last week I started recording the email addresses of the accounts I've been deleting to see if there was a pattern. It seems the @lavabit registrations only use one or two different [hidden email], which are recycled across several account registrations. The account registrations are using names that do not resemble the (99% legit-looking firstlastname@) email addresses. I have tried to ensure that the access controls are such that new registrations cannot create new topics or change existing ones, other than their user topic in all webs. They must be added to a group before they can even work in the Sandbox. This is acceptable for us, because our target audience is not joe-public-internet users. They are not interacting with each other for the first time via the wiki; a new user will sign up and request access to a particular project or an existing project member will give me a heads up to add somebody to their group. I'm off to install BlackListPlugin, but I feel that this sort of plugin isn't what I need - I'm not getting such vast numbers of registrations that I need some imperfect filtering algorithm to create extra work for me. I think the best approach is some sort of UI/dashboard thing for site admins (and hopefully custodians of webs/FooGroup topics) to moderate new (and existing) registrations. My preferred workflow is something like this: * New user signs up, indicating a preference about which project (web/FooGroup) they would like to participate in. * New user enters some sort of moderation queue. * Admin processes their moderation queue. * "Approval" means a user is added to a group or several groups. * Junk accounts are deleted (this includes user topic) and recorded to a log. * Other registrations are sent an E-mail inviting them to request access to or create their own project This largely reflects the current approach for our site. It's not really "the wiki way" but it's demanded by our users who are wary of such open collaboration spaces. -- [hidden email], Ph: (02) 6246 5105 Informatics Technologist - www.taxonomy.org.au Centre for Plant Biodiversity Research CSIRO Plant Industry GPO Box 1600, Canberra ACT 2601 AUSTRALIA ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: Foswiki's registration process is outdated
|
|
In reply to this post by Filippo Salustri
I'd rather have it the other way: spammers can register as they like
but admins would get a one click 'nuke em' button. It would be quite gratifying to make spammers go through an effort to answer captcha and other hoops, then have everything they have "contribute" blown away. A federated response, blacklisting and suspending across sites would make the process almost fun. Still, what can we implement quickly? As it is I'm just going to batch trash the topics, but when I have time. Best, Martin. -- [hidden email] http://twitter.com/mrjcleaver +1 416-786-6752 (GMT-5) On Sun, Dec 20, 2009 at 8:03 PM, Filippo A. Salustri <[hidden email]> wrote: > Is it not reasonable to have a plugin that enforces approval of new > registrations by a member of AdminGroup before the final registration stuff > is done? If this exists, I've not noticed it before. > Cheers. > Fil > > 2009/12/20 Matthias Wientapper <[hidden email]> >> >> On 12/18/09 1:19 PM, Martin Cleaver wrote: >> > Am also suffering from lavabit. >> > >> > Would also like a way to click something in the email to the >> > administrator to handle cases. >> > >> > These would give options to >> > 1) kill this registration >> > 2) block the email domain >> > 3) send a "get lost" email >> > >> > etc. >> > >> > Any ideas? >> > >> >> >> Hi, >> >> today started a new wave of bot based registrations, including wiki spam >> on new user topics. >> >> I had to disable user registration. >> >> This proves that even with BlackListPlugin and WikiSpamPlugin the >> currently existing safety measures to prevent bot or script based >> registrations are not sufficient at all. >> >> This might also have negative effect on the reputation of Foswiki with >> respect to security. >> >> IMHO Foswiki's registration procedure is outdated and unsecure. >> >> I would like to start a discussion based on what was discussed a year >> ago on [1] and [2] and that is e.g. using CAPTCHAs [3] to test for >> humans vs. bots/scripts. This is pretty much a standard for publicly >> open CMS. >> >> Thanks - >> Best, >> /Matthias >> >> [1] http://foswiki.org/Development/RegistrationTopicHandler >> [2] http://foswiki.org/Development/PluggableRegistration >> [3]: http://en.wikipedia.org/wiki/CAPTCHA >> >> >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Foswiki-discuss mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/foswiki-discuss > > > > -- > Filippo A. Salustri, Ph.D., P.Eng. > Mechanical and Industrial Engineering > Ryerson University > 350 Victoria St, Toronto, ON > M5B 2K3, Canada > Tel: 416/979-5000 ext 7749 > Fax: 416/979-5265 > Email: [hidden email] > http://deseng.ryerson.ca/~fil/ > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Foswiki-discuss mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/foswiki-discuss > > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
|
In reply to this post by Paul W Harvey
On a related thread, I suggested it might be reasonable to have a plugin that enforces approval of each new registration by a member of AdminGroup. That would certainly be sufficient for me.
....I too am getting the lavabit spam, and it's getting damned annoying. Cheers. Fil 2009/12/20 Paul W Harvey <[hidden email]> Hi Matthias, -- Filippo A. Salustri, Ph.D., P.Eng. Mechanical and Industrial Engineering Ryerson University 350 Victoria St, Toronto, ON M5B 2K3, Canada Tel: 416/979-5000 ext 7749 Fax: 416/979-5265 Email: [hidden email] http://deseng.ryerson.ca/~fil/ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: Foswiki's registration process is outdated
|
|
In reply to this post by Martin Cleaver
Yup; that would work too. Makes me think of Ripley's line in Aliens: let's nuke 'em from orbit - it's the only way to be sure. :)
Cheers. Fil 2009/12/20 Martin Cleaver <[hidden email]> I'd rather have it the other way: spammers can register as they like -- Filippo A. Salustri, Ph.D., P.Eng. Mechanical and Industrial Engineering Ryerson University 350 Victoria St, Toronto, ON M5B 2K3, Canada Tel: 416/979-5000 ext 7749 Fax: 416/979-5265 Email: [hidden email] http://deseng.ryerson.ca/~fil/ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
In reply to this post by Filippo Salustri
you don't need a plugin for that.
all you need, is to create an AdminApprovedGroup and set your wiki's permissions that you must be a member of that group to do anything. newly registered users will not be in that group, and thus can do nothing. from there, the admin then will need to add users to the groups. Additionally, Paul pointed out that part of the badness is caused by spam links in the rego user topics - to solve that (in the current foswiki) you can create a custom NewUsersTemplate in which the ALLOWTOPICVIEW is set to the AdminApprovedGroup - that way you may be able to flush out approved spamer accounts (if they try to change that) and prevent the links from being public There is some work in foswiki 1.1 that will make this very much easier (the new WikiGroups userinterface, and the add to groups in registration (so that new users can go into an UnApprovedUserGroup - reducing the load on the system when you have too many users in the AdminApprovedGroup) There is no functional deleteUser code - the existing deleteUser only deletes __you__ - for that we need some agreement on what delete does - as in some circumstances the user topic and their contributions should remain, whereas in the spammer case, every change they made should really be rolled back. please, create a feature topic and discuss :) Sven On Sun, 20 Dec 2009 18:24:56 -0500 "Filippo A. Salustri" <[hidden email]> wrote: > On a related thread, I suggested it might be reasonable to have a plugin > that enforces approval of each new registration by a member of AdminGroup. > That would certainly be sufficient for me. > ....I too am getting the lavabit spam, and it's getting damned annoying. > Cheers. > Fil > > 2009/12/20 Paul W Harvey <[hidden email]> > > > Hi Matthias, > > > > > From: Matthias Wientapper <[hidden email]> > > ... > > > I'm getting a couple of successful fake registrations per week, always > > > from the same 16 bit subnet ("M-net" in Germany) and always by using > > > obviously compromised "lavabit.com" mail accounts. > > > > > > Anyone having the same problem? > > > > I am having the same problem also, and it seems these lavabit > > registrations are just the beginning of a bigger campaign. Where I was > > getting four registrations per day for the last couple of weeks from > > @lavabit, today I have 12 registrations: > > 5x lavabit > > 4x gmx > > 1x safe-mail.net > > 1x @mail.ru > > 1x legit registration > > > > Last week I started recording the email addresses of the accounts I've > > been deleting to see if there was a pattern. It seems the @lavabit > > registrations only use one or two different [hidden email], which > > are recycled across several account registrations. The account > > registrations are using names that do not resemble the (99% > > legit-looking firstlastname@) email addresses. > > > > I have tried to ensure that the access controls are such that new > > registrations cannot create new topics or change existing ones, other > > than their user topic in all webs. They must be added to a group before > > they can even work in the Sandbox. > > > > This is acceptable for us, because our target audience is not > > joe-public-internet users. They are not interacting with each other for > > the first time via the wiki; a new user will sign up and request access > > to a particular project or an existing project member will give me a > > heads up to add somebody to their group. > > > > I'm off to install BlackListPlugin, but I feel that this sort of plugin > > isn't what I need - I'm not getting such vast numbers of registrations > > that I need some imperfect filtering algorithm to create extra work for me. > > > > I think the best approach is some sort of UI/dashboard thing for site > > admins (and hopefully custodians of webs/FooGroup topics) to moderate > > new (and existing) registrations. > > > > My preferred workflow is something like this: > > > > * New user signs up, indicating a preference about which project > > (web/FooGroup) they would like to participate in. > > * New user enters some sort of moderation queue. > > * Admin processes their moderation queue. > > * "Approval" means a user is added to a group or several groups. > > * Junk accounts are deleted (this includes user topic) and > > recorded to a log. > > * Other registrations are sent an E-mail inviting them to request > > access to or create their own project > > > > This largely reflects the current approach for our site. It's not really > > "the wiki way" but it's demanded by our users who are wary of such open > > collaboration spaces. > > > > -- > > [hidden email], Ph: (02) 6246 5105 > > Informatics Technologist - www.taxonomy.org.au > > Centre for Plant Biodiversity Research > > CSIRO Plant Industry > > GPO Box 1600, Canberra ACT 2601 AUSTRALIA > > > > > > ------------------------------------------------------------------------------ > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and > > easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > _______________________________________________ > > Foswiki-discuss mailing list > > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/foswiki-discuss > > > > > > -- > Filippo A. Salustri, Ph.D., P.Eng. > Mechanical and Industrial Engineering > Ryerson University > 350 Victoria St, Toronto, ON > M5B 2K3, Canada > Tel: 416/979-5000 ext 7749 > Fax: 416/979-5265 > Email: [hidden email] > http://deseng.ryerson.ca/~fil/ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
|
That's creative (at least, to me it is). It should work fine for wikis like mine, with few users. Thanks for the idea.
Cheers. Fil 2009/12/20 Sven Dowideit <[hidden email]> you don't need a plugin for that. -- Filippo A. Salustri, Ph.D., P.Eng. Mechanical and Industrial Engineering Ryerson University 350 Victoria St, Toronto, ON M5B 2K3, Canada Tel: 416/979-5000 ext 7749 Fax: 416/979-5265 Email: [hidden email] http://deseng.ryerson.ca/~fil/ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
|
just to make it a little easier
please see and comment on: http://foswiki.org/Development/HowToDeleteUserAccount and http://foswiki.org/Tasks/Item4905 the task contains a little analysis of what could be done. Sven On Sun, 20 Dec 2009 20:10:05 -0500 "Filippo A. Salustri" <[hidden email]> wrote: > That's creative (at least, to me it is). It should work fine for wikis like > mine, with few users. Thanks for the idea. > Cheers. > Fil > > 2009/12/20 Sven Dowideit <[hidden email]> > > > you don't need a plugin for that. > > > > all you need, is to create an AdminApprovedGroup and set your wiki's > > permissions that you must be a member of that group to do anything. > > > > newly registered users will not be in that group, and thus can do nothing. > > > > from there, the admin then will need to add users to the groups. > > > > Additionally, Paul pointed out that part of the badness is caused by spam > > links in the rego user topics - to solve that (in the current foswiki) you > > can create a custom NewUsersTemplate in which the ALLOWTOPICVIEW is set to > > the AdminApprovedGroup - that way you may be able to flush out approved > > spamer accounts (if they try to change that) and prevent the links from > > being public > > > > There is some work in foswiki 1.1 that will make this very much easier (the > > new WikiGroups userinterface, and the add to groups in registration (so that > > new users can go into an UnApprovedUserGroup - reducing the load on the > > system when you have too many users in the AdminApprovedGroup) > > > > There is no functional deleteUser code - the existing deleteUser only > > deletes __you__ - for that we need some agreement on what delete does - as > > in some circumstances the user topic and their contributions should remain, > > whereas in the spammer case, every change they made should really be rolled > > back. > > > > please, create a feature topic and discuss :) > > > > Sven > > > > > > On Sun, 20 Dec 2009 18:24:56 -0500 > > "Filippo A. Salustri" <[hidden email]> wrote: > > > > > On a related thread, I suggested it might be reasonable to have a plugin > > > that enforces approval of each new registration by a member of > > AdminGroup. > > > That would certainly be sufficient for me. > > > ....I too am getting the lavabit spam, and it's getting damned annoying. > > > Cheers. > > > Fil > > > > > > 2009/12/20 Paul W Harvey <[hidden email]> > > > > > > > Hi Matthias, > > > > > > > > > From: Matthias Wientapper <[hidden email]> > > > > ... > > > > > I'm getting a couple of successful fake registrations per week, > > always > > > > > from the same 16 bit subnet ("M-net" in Germany) and always by using > > > > > obviously compromised "lavabit.com" mail accounts. > > > > > > > > > > Anyone having the same problem? > > > > > > > > I am having the same problem also, and it seems these lavabit > > > > registrations are just the beginning of a bigger campaign. Where I was > > > > getting four registrations per day for the last couple of weeks from > > > > @lavabit, today I have 12 registrations: > > > > 5x lavabit > > > > 4x gmx > > > > 1x safe-mail.net > > > > 1x @mail.ru > > > > 1x legit registration > > > > > > > > Last week I started recording the email addresses of the accounts I've > > > > been deleting to see if there was a pattern. It seems the @lavabit > > > > registrations only use one or two different [hidden email], > > which > > > > are recycled across several account registrations. The account > > > > registrations are using names that do not resemble the (99% > > > > legit-looking firstlastname@) email addresses. > > > > > > > > I have tried to ensure that the access controls are such that new > > > > registrations cannot create new topics or change existing ones, other > > > > than their user topic in all webs. They must be added to a group before > > > > they can even work in the Sandbox. > > > > > > > > This is acceptable for us, because our target audience is not > > > > joe-public-internet users. They are not interacting with each other for > > > > the first time via the wiki; a new user will sign up and request access > > > > to a particular project or an existing project member will give me a > > > > heads up to add somebody to their group. > > > > > > > > I'm off to install BlackListPlugin, but I feel that this sort of plugin > > > > isn't what I need - I'm not getting such vast numbers of registrations > > > > that I need some imperfect filtering algorithm to create extra work for > > me. > > > > > > > > I think the best approach is some sort of UI/dashboard thing for site > > > > admins (and hopefully custodians of webs/FooGroup topics) to moderate > > > > new (and existing) registrations. > > > > > > > > My preferred workflow is something like this: > > > > > > > > * New user signs up, indicating a preference about which project > > > > (web/FooGroup) they would like to participate in. > > > > * New user enters some sort of moderation queue. > > > > * Admin processes their moderation queue. > > > > * "Approval" means a user is added to a group or several groups. > > > > * Junk accounts are deleted (this includes user topic) and > > > > recorded to a log. > > > > * Other registrations are sent an E-mail inviting them to request > > > > access to or create their own project > > > > > > > > This largely reflects the current approach for our site. It's not > > really > > > > "the wiki way" but it's demanded by our users who are wary of such open > > > > collaboration spaces. > > > > > > > > -- > > > > [hidden email], Ph: (02) 6246 5105 > > > > Informatics Technologist - www.taxonomy.org.au > > > > Centre for Plant Biodiversity Research > > > > CSIRO Plant Industry > > > > GPO Box 1600, Canberra ACT 2601 AUSTRALIA > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > This SF.Net email is sponsored by the Verizon Developer Community > > > > Take advantage of Verizon's best-in-class app development support > > > > A streamlined, 14 day to market process makes app distribution fast and > > > > easy > > > > Join now and get one step closer to millions of Verizon customers > > > > http://p.sf.net/sfu/verizon-dev2dev > > > > _______________________________________________ > > > > Foswiki-discuss mailing list > > > > [hidden email] > > > > https://lists.sourceforge.net/lists/listinfo/foswiki-discuss > > > > > > > > > > > > > > > > -- > > > Filippo A. Salustri, Ph.D., P.Eng. > > > Mechanical and Industrial Engineering > > > Ryerson University > > > 350 Victoria St, Toronto, ON > > > M5B 2K3, Canada > > > Tel: 416/979-5000 ext 7749 > > > Fax: 416/979-5265 > > > Email: [hidden email] > > > http://deseng.ryerson.ca/~fil/ <http://deseng.ryerson.ca/%7Efil/> > > > > > > -- > Filippo A. Salustri, Ph.D., P.Eng. > Mechanical and Industrial Engineering > Ryerson University > 350 Victoria St, Toronto, ON > M5B 2K3, Canada > Tel: 416/979-5000 ext 7749 > Fax: 416/979-5265 > Email: [hidden email] > http://deseng.ryerson.ca/~fil/ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
In reply to this post by Sven Dowideit
That is what I have been using since that other trademarked wiki as
well. Either that or fully external user management (LDAP). It works 100%. Brgds, On Mon, 2009-12-21 at 10:36 +1000, Sven Dowideit wrote: > you don't need a plugin for that. > > all you need, is to create an AdminApprovedGroup and set your wiki's permissions that you must be a member of that group to do anything. > > newly registered users will not be in that group, and thus can do nothing. > > from there, the admin then will need to add users to the groups. > > Additionally, Paul pointed out that part of the badness is caused by spam links in the rego user topics - to solve that (in the current foswiki) you can create a custom NewUsersTemplate in which the ALLOWTOPICVIEW is set to the AdminApprovedGroup - that way you may be able to flush out approved spamer accounts (if they try to change that) and prevent the links from being public > > There is some work in foswiki 1.1 that will make this very much easier (the new WikiGroups userinterface, and the add to groups in registration (so that new users can go into an UnApprovedUserGroup - reducing the load on the system when you have too many users in the AdminApprovedGroup) > > There is no functional deleteUser code - the existing deleteUser only deletes __you__ - for that we need some agreement on what delete does - as in some circumstances the user topic and their contributions should remain, whereas in the spammer case, every change they made should really be rolled back. > > please, create a feature topic and discuss :) > > Sven > > > On Sun, 20 Dec 2009 18:24:56 -0500 > "Filippo A. Salustri" <[hidden email]> wrote: > > > On a related thread, I suggested it might be reasonable to have a plugin > > that enforces approval of each new registration by a member of AdminGroup. > > That would certainly be sufficient for me. > > ....I too am getting the lavabit spam, and it's getting damned annoying. > > Cheers. > > Fil > > > > 2009/12/20 Paul W Harvey <[hidden email]> > > > > > Hi Matthias, > > > > > > > From: Matthias Wientapper <[hidden email]> > > > ... > > > > I'm getting a couple of successful fake registrations per week, always > > > > from the same 16 bit subnet ("M-net" in Germany) and always by using > > > > obviously compromised "lavabit.com" mail accounts. > > > > > > > > Anyone having the same problem? > > > > > > I am having the same problem also, and it seems these lavabit > > > registrations are just the beginning of a bigger campaign. Where I was > > > getting four registrations per day for the last couple of weeks from > > > @lavabit, today I have 12 registrations: > > > 5x lavabit > > > 4x gmx > > > 1x safe-mail.net > > > 1x @mail.ru > > > 1x legit registration > > > > > > Last week I started recording the email addresses of the accounts I've > > > been deleting to see if there was a pattern. It seems the @lavabit > > > registrations only use one or two different [hidden email], which > > > are recycled across several account registrations. The account > > > registrations are using names that do not resemble the (99% > > > legit-looking firstlastname@) email addresses. > > > > > > I have tried to ensure that the access controls are such that new > > > registrations cannot create new topics or change existing ones, other > > > than their user topic in all webs. They must be added to a group before > > > they can even work in the Sandbox. > > > > > > This is acceptable for us, because our target audience is not > > > joe-public-internet users. They are not interacting with each other for > > > the first time via the wiki; a new user will sign up and request access > > > to a particular project or an existing project member will give me a > > > heads up to add somebody to their group. > > > > > > I'm off to install BlackListPlugin, but I feel that this sort of plugin > > > isn't what I need - I'm not getting such vast numbers of registrations > > > that I need some imperfect filtering algorithm to create extra work for me. > > > > > > I think the best approach is some sort of UI/dashboard thing for site > > > admins (and hopefully custodians of webs/FooGroup topics) to moderate > > > new (and existing) registrations. > > > > > > My preferred workflow is something like this: > > > > > > * New user signs up, indicating a preference about which project > > > (web/FooGroup) they would like to participate in. > > > * New user enters some sort of moderation queue. > > > * Admin processes their moderation queue. > > > * "Approval" means a user is added to a group or several groups. > > > * Junk accounts are deleted (this includes user topic) and > > > recorded to a log. > > > * Other registrations are sent an E-mail inviting them to request > > > access to or create their own project > > > > > > This largely reflects the current approach for our site. It's not really > > > "the wiki way" but it's demanded by our users who are wary of such open > > > collaboration spaces. > > > > > > -- > > > [hidden email], Ph: (02) 6246 5105 > > > Informatics Technologist - www.taxonomy.org.au > > > Centre for Plant Biodiversity Research > > > CSIRO Plant Industry > > > GPO Box 1600, Canberra ACT 2601 AUSTRALIA > > > > > > > > > ------------------------------------------------------------------------------ > > > This SF.Net email is sponsored by the Verizon Developer Community > > > Take advantage of Verizon's best-in-class app development support > > > A streamlined, 14 day to market process makes app distribution fast and > > > easy > > > Join now and get one step closer to millions of Verizon customers > > > http://p.sf.net/sfu/verizon-dev2dev > > > _______________________________________________ > > > Foswiki-discuss mailing list > > > [hidden email] > > > https://lists.sourceforge.net/lists/listinfo/foswiki-discuss > > > > > > > > > > > -- > > Filippo A. Salustri, Ph.D., P.Eng. > > Mechanical and Industrial Engineering > > Ryerson University > > 350 Victoria St, Toronto, ON > > M5B 2K3, Canada > > Tel: 416/979-5000 ext 7749 > > Fax: 416/979-5265 > > Email: [hidden email] > > http://deseng.ryerson.ca/~fil/ > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Foswiki-discuss mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/foswiki-discuss > Understanding is a three-edged sword: your side, their side, and the truth. --Kosh Naranek A. R. Ivanov E-mail: [hidden email] WWW: http://www.sigsegv.cx/ pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <[hidden email]> Fingerprint: C824 CBD7 EE4B D7F8 5331 89D5 FCDA 572E DDE5 E715 ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
|
> or fully external user management (LDAP)
Indeed, like Facebook, OpenID or (at a push) twitter. M. -- [hidden email] http://twitter.com/mrjcleaver +1 416-786-6752 (GMT-5) On Mon, Dec 21, 2009 at 11:14 AM, Anton Ivanov <[hidden email]> wrote: > That is what I have been using since that other trademarked wiki as > well. Either that or fully external user management (LDAP). > > It works 100%. > > Brgds, > > On Mon, 2009-12-21 at 10:36 +1000, Sven Dowideit wrote: >> you don't need a plugin for that. >> >> all you need, is to create an AdminApprovedGroup and set your wiki's permissions that you must be a member of that group to do anything. >> >> newly registered users will not be in that group, and thus can do nothing. >> >> from there, the admin then will need to add users to the groups. >> >> Additionally, Paul pointed out that part of the badness is caused by spam links in the rego user topics - to solve that (in the current foswiki) you can create a custom NewUsersTemplate in which the ALLOWTOPICVIEW is set to the AdminApprovedGroup - that way you may be able to flush out approved spamer accounts (if they try to change that) and prevent the links from being public >> >> There is some work in foswiki 1.1 that will make this very much easier (the new WikiGroups userinterface, and the add to groups in registration (so that new users can go into an UnApprovedUserGroup - reducing the load on the system when you have too many users in the AdminApprovedGroup) >> >> There is no functional deleteUser code - the existing deleteUser only deletes __you__ - for that we need some agreement on what delete does - as in some circumstances the user topic and their contributions should remain, whereas in the spammer case, every change they made should really be rolled back. >> >> please, create a feature topic and discuss :) >> >> Sven >> >> >> On Sun, 20 Dec 2009 18:24:56 -0500 >> "Filippo A. Salustri" <[hidden email]> wrote: >> >> > On a related thread, I suggested it might be reasonable to have a plugin >> > that enforces approval of each new registration by a member of AdminGroup. >> > That would certainly be sufficient for me. >> > ....I too am getting the lavabit spam, and it's getting damned annoying. >> > Cheers. >> > Fil >> > >> > 2009/12/20 Paul W Harvey <[hidden email]> >> > >> > > Hi Matthias, >> > > >> > > > From: Matthias Wientapper <[hidden email]> >> > > ... >> > > > I'm getting a couple of successful fake registrations per week, always >> > > > from the same 16 bit subnet ("M-net" in Germany) and always by using >> > > > obviously compromised "lavabit.com" mail accounts. >> > > > >> > > > Anyone having the same problem? >> > > >> > > I am having the same problem also, and it seems these lavabit >> > > registrations are just the beginning of a bigger campaign. Where I was >> > > getting four registrations per day for the last couple of weeks from >> > > @lavabit, today I have 12 registrations: >> > > 5x lavabit >> > > 4x gmx >> > > 1x safe-mail.net >> > > 1x @mail.ru >> > > 1x legit registration >> > > >> > > Last week I started recording the email addresses of the accounts I've >> > > been deleting to see if there was a pattern. It seems the @lavabit >> > > registrations only use one or two different [hidden email], which >> > > are recycled across several account registrations. The account >> > > registrations are using names that do not resemble the (99% >> > > legit-looking firstlastname@) email addresses. >> > > >> > > I have tried to ensure that the access controls are such that new >> > > registrations cannot create new topics or change existing ones, other >> > > than their user topic in all webs. They must be added to a group before >> > > they can even work in the Sandbox. >> > > >> > > This is acceptable for us, because our target audience is not >> > > joe-public-internet users. They are not interacting with each other for >> > > the first time via the wiki; a new user will sign up and request access >> > > to a particular project or an existing project member will give me a >> > > heads up to add somebody to their group. >> > > >> > > I'm off to install BlackListPlugin, but I feel that this sort of plugin >> > > isn't what I need - I'm not getting such vast numbers of registrations >> > > that I need some imperfect filtering algorithm to create extra work for me. >> > > >> > > I think the best approach is some sort of UI/dashboard thing for site >> > > admins (and hopefully custodians of webs/FooGroup topics) to moderate >> > > new (and existing) registrations. >> > > >> > > My preferred workflow is something like this: >> > > >> > > * New user signs up, indicating a preference about which project >> > > (web/FooGroup) they would like to participate in. >> > > * New user enters some sort of moderation queue. >> > > * Admin processes their moderation queue. >> > > * "Approval" means a user is added to a group or several groups. >> > > * Junk accounts are deleted (this includes user topic) and >> > > recorded to a log. >> > > * Other registrations are sent an E-mail inviting them to request >> > > access to or create their own project >> > > >> > > This largely reflects the current approach for our site. It's not really >> > > "the wiki way" but it's demanded by our users who are wary of such open >> > > collaboration spaces. >> > > >> > > -- >> > > [hidden email], Ph: (02) 6246 5105 >> > > Informatics Technologist - www.taxonomy.org.au >> > > Centre for Plant Biodiversity Research >> > > CSIRO Plant Industry >> > > GPO Box 1600, Canberra ACT 2601 AUSTRALIA >> > > >> > > >> > > ------------------------------------------------------------------------------ >> > > This SF.Net email is sponsored by the Verizon Developer Community >> > > Take advantage of Verizon's best-in-class app development support >> > > A streamlined, 14 day to market process makes app distribution fast and >> > > easy >> > > Join now and get one step closer to millions of Verizon customers >> > > http://p.sf.net/sfu/verizon-dev2dev >> > > _______________________________________________ >> > > Foswiki-discuss mailing list >> > > [hidden email] >> > > https://lists.sourceforge.net/lists/listinfo/foswiki-discuss >> > > >> > >> > >> > >> > -- >> > Filippo A. Salustri, Ph.D., P.Eng. >> > Mechanical and Industrial Engineering >> > Ryerson University >> > 350 Victoria St, Toronto, ON >> > M5B 2K3, Canada >> > Tel: 416/979-5000 ext 7749 >> > Fax: 416/979-5265 >> > Email: [hidden email] >> > http://deseng.ryerson.ca/~fil/ >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Foswiki-discuss mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/foswiki-discuss >> > -- > Understanding is a three-edged sword: > your side, their side, and the truth. --Kosh Naranek > > A. R. Ivanov > E-mail: [hidden email] > WWW: http://www.sigsegv.cx/ > pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <[hidden email]> > Fingerprint: C824 CBD7 EE4B D7F8 5331 89D5 FCDA 572E DDE5 E715 > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Foswiki-discuss mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/foswiki-discuss > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
|
In reply to this post by Sven Dowideit
Hi,
Thanks for the work around that will prevent spammers from doing harm. IMHO this cures the symptom but not the cause and that is that spammers can easily and automatically sign up. What if I dont want spammer accounts annoyingly clogging up my installation? That leaves the question how to *prevent* fake registration effectively in the first place. -- Best regards, /Matthias (Sent from mobile) On 21.12.2009, at 01:36, Sven Dowideit <[hidden email]> wrote: > you don't need a plugin for that. > > all you need, is to create an AdminApprovedGroup and set your wiki's > permissions that you must be a member of that group to do anything. > > newly registered users will not be in that group, and thus can do > nothing. > > from there, the admin then will need to add users to the groups. > > Additionally, Paul pointed out that part of the badness is caused by > spam links in the rego user topics - to solve that (in the current > foswiki) you can create a custom NewUsersTemplate in which the > ALLOWTOPICVIEW is set to the AdminApprovedGroup - that way you may > be able to flush out approved spamer accounts (if they try to change > that) and prevent the links from being public > > There is some work in foswiki 1.1 that will make this very much > easier (the new WikiGroups userinterface, and the add to groups in > registration (so that new users can go into an UnApprovedUserGroup - > reducing the load on the system when you have too many users in the > AdminApprovedGroup) > > There is no functional deleteUser code - the existing deleteUser > only deletes __you__ - for that we need some agreement on what > delete does - as in some circumstances the user topic and their > contributions should remain, whereas in the spammer case, every > change they made should really be rolled back. > > please, create a feature topic and discuss :) > > Sven > > > On Sun, 20 Dec 2009 18:24:56 -0500 > "Filippo A. Salustri" <[hidden email]> wrote: > >> On a related thread, I suggested it might be reasonable to have a >> plugin >> that enforces approval of each new registration by a member of >> AdminGroup. >> That would certainly be sufficient for me. >> ....I too am getting the lavabit spam, and it's getting damned >> annoying. >> Cheers. >> Fil >> >> 2009/12/20 Paul W Harvey <[hidden email]> >> >>> Hi Matthias, >>> >>>> From: Matthias Wientapper <[hidden email]> >>> ... >>>> I'm getting a couple of successful fake registrations per week, >>>> always >>>> from the same 16 bit subnet ("M-net" in Germany) and always by >>>> using >>>> obviously compromised "lavabit.com" mail accounts. >>>> >>>> Anyone having the same problem? >>> >>> I am having the same problem also, and it seems these lavabit >>> registrations are just the beginning of a bigger campaign. Where I >>> was >>> getting four registrations per day for the last couple of weeks from >>> @lavabit, today I have 12 registrations: >>> 5x lavabit >>> 4x gmx >>> 1x safe-mail.net >>> 1x @mail.ru >>> 1x legit registration >>> >>> Last week I started recording the email addresses of the accounts >>> I've >>> been deleting to see if there was a pattern. It seems the @lavabit >>> registrations only use one or two different [hidden email], >>> which >>> are recycled across several account registrations. The account >>> registrations are using names that do not resemble the (99% >>> legit-looking firstlastname@) email addresses. >>> >>> I have tried to ensure that the access controls are such that new >>> registrations cannot create new topics or change existing ones, >>> other >>> than their user topic in all webs. They must be added to a group >>> before >>> they can even work in the Sandbox. >>> >>> This is acceptable for us, because our target audience is not >>> joe-public-internet users. They are not interacting with each >>> other for >>> the first time via the wiki; a new user will sign up and request >>> access >>> to a particular project or an existing project member will give me a >>> heads up to add somebody to their group. >>> >>> I'm off to install BlackListPlugin, but I feel that this sort of >>> plugin >>> isn't what I need - I'm not getting such vast numbers of >>> registrations >>> that I need some imperfect filtering algorithm to create extra >>> work for me. >>> >>> I think the best approach is some sort of UI/dashboard thing for >>> site >>> admins (and hopefully custodians of webs/FooGroup topics) to >>> moderate >>> new (and existing) registrations. >>> >>> My preferred workflow is something like this: >>> >>> * New user signs up, indicating a preference about which project >>> (web/FooGroup) they would like to participate in. >>> * New user enters some sort of moderation queue. >>> * Admin processes their moderation queue. >>> * "Approval" means a user is added to a group or several >>> groups. >>> * Junk accounts are deleted (this includes user topic) and >>> recorded to a log. >>> * Other registrations are sent an E-mail inviting them to >>> request >>> access to or create their own project >>> >>> This largely reflects the current approach for our site. It's not >>> really >>> "the wiki way" but it's demanded by our users who are wary of such >>> open >>> collaboration spaces. >>> >>> -- >>> [hidden email], Ph: (02) 6246 5105 >>> Informatics Technologist - www.taxonomy.org.au >>> Centre for Plant Biodiversity Research >>> CSIRO Plant Industry >>> GPO Box 1600, Canberra ACT 2601 AUSTRALIA >>> >>> >>> --- >>> --- >>> --- >>> --- >>> ------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution >>> fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> Foswiki-discuss mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/foswiki-discuss >>> >> >> >> >> -- >> Filippo A. Salustri, Ph.D., P.Eng. >> Mechanical and Industrial Engineering >> Ryerson University >> 350 Victoria St, Toronto, ON >> M5B 2K3, Canada >> Tel: 416/979-5000 ext 7749 >> Fax: 416/979-5265 >> Email: [hidden email] >> http://deseng.ryerson.ca/~fil/ > > --- > --- > --- > --------------------------------------------------------------------- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast > and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Foswiki-discuss mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/foswiki-discuss ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
|
I agree completely.
I'm running two small sites as support tools for scientific projects. Most of the wiki topics are already readable only to users listed in some gropus, but the amount of spam registrations is becoming larger than the number of legitimate users. I can easily spot out spammers, but editing the .htaccess file and removing related topics is a time consuming task (and prone to errors, too). I'd like an "approval" mechanism which prevents unapproved registrations to leave any trace on the wiki site. Cheers, l.f. Matthias Wientapper wrote: > Hi, > > Thanks for the work around that will prevent spammers from doing harm. > IMHO this cures the symptom but not the cause and that is that > spammers can easily and automatically sign up. > > What if I dont want spammer accounts annoyingly clogging up my > installation? That leaves the question how to *prevent* fake > registration effectively in the first place. > -- ---------------------------------------------------------------------- Luca Fini Tel: +39 055 2752 307 INAF - Oss. Astrofisico di Arcetri Fax: +39 055 2752 292 L.go E.Fermi, 5. 50125 Firenze mailto:[hidden email] http://www.arcetri.inaf.it/~lfini ---------------------------------------------------------------------- ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
In reply to this post by Sven Dowideit
The ApprovedUserGroup is what I use, and it effectively defeats the
spammers from getting in. However, I think this should be a standard feature provided in the basic install because you really can't run a (public) foswiki site without it. If new registrations are not approved, then after a period of time, they should be auto-deleted from the user list by a cron job. At present, you will get a plethora of bogus users set up by these robotic spam engines. --Raymond On 12/21/2009 8:36 AM, Sven Dowideit wrote: > you don't need a plugin for that. > > all you need, is to create an AdminApprovedGroup and set your wiki's permissions that you must be a member of that group to do anything. > > newly registered users will not be in that group, and thus can do nothing. > > from there, the admin then will need to add users to the groups. > > Additionally, Paul pointed out that part of the badness is caused by spam links in the rego user topics - to solve that (in the current foswiki) you can create a custom NewUsersTemplate in which the ALLOWTOPICVIEW is set to the AdminApprovedGroup - that way you may be able to flush out approved spamer accounts (if they try to change that) and prevent the links from being public > > There is some work in foswiki 1.1 that will make this very much easier (the new WikiGroups userinterface, and the add to groups in registration (so that new users can go into an UnApprovedUserGroup - reducing the load on the system when you have too many users in the AdminApprovedGroup) > > There is no functional deleteUser code - the existing deleteUser only deletes __you__ - for that we need some agreement on what delete does - as in some circumstances the user topic and their contributions should remain, whereas in the spammer case, every change they made should really be rolled back. > > please, create a feature topic and discuss :) > > Sven > > > On Sun, 20 Dec 2009 18:24:56 -0500 > "Filippo A. Salustri"<[hidden email]> wrote: > > >> On a related thread, I suggested it might be reasonable to have a plugin >> that enforces approval of each new registration by a member of AdminGroup. >> That would certainly be sufficient for me. >> ....I too am getting the lavabit spam, and it's getting damned annoying. >> Cheers. >> Fil >> >> 2009/12/20 Paul W Harvey<[hidden email]> >> >> >>> Hi Matthias, >>> >>> >>>> From: Matthias Wientapper<[hidden email]> >>>> >>> ... >>> >>>> I'm getting a couple of successful fake registrations per week, always >>>> from the same 16 bit subnet ("M-net" in Germany) and always by using >>>> obviously compromised "lavabit.com" mail accounts. >>>> >>>> Anyone having the same problem? >>>> >>> I am having the same problem also, and it seems these lavabit >>> registrations are just the beginning of a bigger campaign. Where I was >>> getting four registrations per day for the last couple of weeks from >>> @lavabit, today I have 12 registrations: >>> 5x lavabit >>> 4x gmx >>> 1x safe-mail.net >>> 1x @mail.ru >>> 1x legit registration >>> >>> Last week I started recording the email addresses of the accounts I've >>> been deleting to see if there was a pattern. It seems the @lavabit >>> registrations only use one or two different [hidden email], which >>> are recycled across several account registrations. The account >>> registrations are using names that do not resemble the (99% >>> legit-looking firstlastname@) email addresses. >>> >>> I have tried to ensure that the access controls are such that new >>> registrations cannot create new topics or change existing ones, other >>> than their user topic in all webs. They must be added to a group before >>> they can even work in the Sandbox. >>> >>> This is acceptable for us, because our target audience is not >>> joe-public-internet users. They are not interacting with each other for >>> the first time via the wiki; a new user will sign up and request access >>> to a particular project or an existing project member will give me a >>> heads up to add somebody to their group. >>> >>> I'm off to install BlackListPlugin, but I feel that this sort of plugin >>> isn't what I need - I'm not getting such vast numbers of registrations >>> that I need some imperfect filtering algorithm to create extra work for me. >>> >>> I think the best approach is some sort of UI/dashboard thing for site >>> admins (and hopefully custodians of webs/FooGroup topics) to moderate >>> new (and existing) registrations. >>> >>> My preferred workflow is something like this: >>> >>> * New user signs up, indicating a preference about which project >>> (web/FooGroup) they would like to participate in. >>> * New user enters some sort of moderation queue. >>> * Admin processes their moderation queue. >>> * "Approval" means a user is added to a group or several groups. >>> * Junk accounts are deleted (this includes user topic) and >>> recorded to a log. >>> * Other registrations are sent an E-mail inviting them to request >>> access to or create their own project >>> >>> This largely reflects the current approach for our site. It's not really >>> "the wiki way" but it's demanded by our users who are wary of such open >>> collaboration spaces. >>> >>> -- >>> [hidden email], Ph: (02) 6246 5105 >>> Informatics Technologist - www.taxonomy.org.au >>> Centre for Plant Biodiversity Research >>> CSIRO Plant Industry >>> GPO Box 1600, Canberra ACT 2601 AUSTRALIA >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> Foswiki-discuss mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/foswiki-discuss >>> >>> >> >> >> -- >> Filippo A. Salustri, Ph.D., P.Eng. >> Mechanical and Industrial Engineering >> Ryerson University >> 350 Victoria St, Toronto, ON >> M5B 2K3, Canada >> Tel: 416/979-5000 ext 7749 >> Fax: 416/979-5265 >> Email: [hidden email] >> http://deseng.ryerson.ca/~fil/ >> > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Foswiki-discuss mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/foswiki-discuss > > -- --------------------------------------- Raymond Lutz Cognisys, Inc. 1010 Old Chase Ave., Bldg B El Cajon (San Diego Cty), CA 92020 USA Voice 619-447-3246 http//www.cognisys.com ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
I do not agree this should be standard.
First, I think it is the common assumption that Foswiki target group is mainly businesses used for internal information and collaborarion. And this means safely put behind a firewall. Default setup should not be annoying to our main target group. Second. If Foswiki is used outside a firewall your method will also in many (not all) have a very undesired effect. If an public Foswiki has the goal to enable a limited target group to collaborate on something and let the general public only read your method is great. But if you also want casual users to contribute, having an approval flow that takes hours or days will put them off. An example is my Motion open source project. I use Foswiki for collaboration but I also use it for users to report bugs and provide feedback. If I imposed an approval cycle more than half the people would think "to heck with that" and simply not report the bug or provide the bugfix. I can see already many sending me mails because even the registration puts them off. People have very little patience and if they have to wait till you get the time to approve their registration to report a bug risk is high they never return the next day. Just look ar the many people that report a bug on foswiki.org and never return to provide feedback. If you want this kind of dialogue with your users or customers you need to use other means to fight spam. The approval method is good in some cases but in most cases it would be an unwanted feature and for sure not something we should have as a default. I am working on improving the BlackListPlugin so it becomes less of a denial of service attack vector and I have fixed at least 4 bugs. I am currently trying to improve some additional features on it. Give me a few more days and I will have a release for you. Foswiki 1.0.9 to be released soon will by default have strikeone protection for registrations. Kenneth On 27 Dec 2009, at 00:01, Raymond Lutz <[hidden email]> wrote: > The ApprovedUserGroup is what I use, and it effectively defeats the > spammers from getting in. However, I think this should be a standard > feature provided in the basic install because you really can't run a > (public) foswiki site without it. If new registrations are not > approved, > then after a period of time, they should be auto-deleted from the user > list by a cron job. At present, you will get a plethora of bogus users > set up by these robotic spam engines. > --Raymond > > On 12/21/2009 8:36 AM, Sven Dowideit wrote: >> you don't need a plugin for that. >> >> all you need, is to create an AdminApprovedGroup and set your >> wiki's permissions that you must be a member of that group to do >> anything. >> >> newly registered users will not be in that group, and thus can do >> nothing. >> >> from there, the admin then will need to add users to the groups. >> >> Additionally, Paul pointed out that part of the badness is caused >> by spam links in the rego user topics - to solve that (in the >> current foswiki) you can create a custom NewUsersTemplate in which >> the ALLOWTOPICVIEW is set to the AdminApprovedGroup - that way you >> may be able to flush out approved spamer accounts (if they try to >> change that) and prevent the links from being public >> >> There is some work in foswiki 1.1 that will make this very much >> easier (the new WikiGroups userinterface, and the add to groups in >> registration (so that new users can go into an UnApprovedUserGroup >> - reducing the load on the system when you have too many users in >> the AdminApprovedGroup) >> >> There is no functional deleteUser code - the existing deleteUser >> only deletes __you__ - for that we need some agreement on what >> delete does - as in some circumstances the user topic and their >> contributions should remain, whereas in the spammer case, every >> change they made should really be rolled back. >> >> please, create a feature topic and discuss :) >> >> Sven >> >> >> On Sun, 20 Dec 2009 18:24:56 -0500 >> "Filippo A. Salustri"<[hidden email]> wrote: >> >> >>> On a related thread, I suggested it might be reasonable to have a >>> plugin >>> that enforces approval of each new registration by a member of >>> AdminGroup. >>> That would certainly be sufficient for me. >>> ....I too am getting the lavabit spam, and it's getting damned >>> annoying. >>> Cheers. >>> Fil >>> >>> 2009/12/20 Paul W Harvey<[hidden email]> >>> >>> >>>> Hi Matthias, >>>> >>>> >>>>> From: Matthias Wientapper<[hidden email]> >>>>> >>>> ... >>>> >>>>> I'm getting a couple of successful fake registrations per week, >>>>> always >>>>> from the same 16 bit subnet ("M-net" in Germany) and always by >>>>> using >>>>> obviously compromised "lavabit.com" mail accounts. >>>>> >>>>> Anyone having the same problem? >>>>> >>>> I am having the same problem also, and it seems these lavabit >>>> registrations are just the beginning of a bigger campaign. Where >>>> I was >>>> getting four registrations per day for the last couple of weeks >>>> from >>>> @lavabit, today I have 12 registrations: >>>> 5x lavabit >>>> 4x gmx >>>> 1x safe-mail.net >>>> 1x @mail.ru >>>> 1x legit registration >>>> >>>> Last week I started recording the email addresses of the accounts >>>> I've >>>> been deleting to see if there was a pattern. It seems the @lavabit >>>> registrations only use one or two different >>>> [hidden email], which >>>> are recycled across several account registrations. The account >>>> registrations are using names that do not resemble the (99% >>>> legit-looking firstlastname@) email addresses. >>>> >>>> I have tried to ensure that the access controls are such that new >>>> registrations cannot create new topics or change existing ones, >>>> other >>>> than their user topic in all webs. They must be added to a group >>>> before >>>> they can even work in the Sandbox. >>>> >>>> This is acceptable for us, because our target audience is not >>>> joe-public-internet users. They are not interacting with each >>>> other for >>>> the first time via the wiki; a new user will sign up and request >>>> access >>>> to a particular project or an existing project member will give >>>> me a >>>> heads up to add somebody to their group. >>>> >>>> I'm off to install BlackListPlugin, but I feel that this sort of >>>> plugin >>>> isn't what I need - I'm not getting such vast numbers of >>>> registrations >>>> that I need some imperfect filtering algorithm to create extra >>>> work for me. >>>> >>>> I think the best approach is some sort of UI/dashboard thing for >>>> site >>>> admins (and hopefully custodians of webs/FooGroup topics) to >>>> moderate >>>> new (and existing) registrations. >>>> >>>> My preferred workflow is something like this: >>>> >>>> * New user signs up, indicating a preference about which project >>>> (web/FooGroup) they would like to participate in. >>>> * New user enters some sort of moderation queue. >>>> * Admin processes their moderation queue. >>>> * "Approval" means a user is added to a group or several >>>> groups. >>>> * Junk accounts are deleted (this includes user topic) and >>>> recorded to a log. >>>> * Other registrations are sent an E-mail inviting them to >>>> request >>>> access to or create their own project >>>> >>>> This largely reflects the current approach for our site. It's not >>>> really >>>> "the wiki way" but it's demanded by our users who are wary of >>>> such open >>>> collaboration spaces. >>>> >>>> -- >>>> [hidden email], Ph: (02) 6246 5105 >>>> Informatics Technologist - www.taxonomy.org.au >>>> Centre for Plant Biodiversity Research >>>> CSIRO Plant Industry >>>> GPO Box 1600, Canberra ACT 2601 AUSTRALIA >>>> >>>> >>>> --- >>>> --- >>>> --- >>>> --- >>>> ------------------------------------------------------------------ >>>> This SF.Net email is sponsored by the Verizon Developer Community >>>> Take advantage of Verizon's best-in-class app development support >>>> A streamlined, 14 day to market process makes app distribution >>>> fast and >>>> easy >>>> Join now and get one step closer to millions of Verizon customers >>>> http://p.sf.net/sfu/verizon-dev2dev >>>> _______________________________________________ >>>> Foswiki-discuss mailing list >>>> [hidden email] >>>> https://lists.sourceforge.net/lists/listinfo/foswiki-discuss >>>> >>>> >>> >>> >>> -- >>> Filippo A. Salustri, Ph.D., P.Eng. >>> Mechanical and Industrial Engineering >>> Ryerson University >>> 350 Victoria St, Toronto, ON >>> M5B 2K3, Canada >>> Tel: 416/979-5000 ext 7749 >>> Fax: 416/979-5265 >>> Email: [hidden email] >>> http://deseng.ryerson.ca/~fil/ >>> >> --- >> --- >> --- >> --------------------------------------------------------------------- >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast >> and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Foswiki-discuss mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/foswiki-discuss >> >> > > -- > --------------------------------------- > Raymond Lutz > Cognisys, Inc. > 1010 Old Chase Ave., Bldg B > El Cajon (San Diego Cty), CA 92020 USA > Voice 619-447-3246 > http//www.cognisys.com > > > --- > --- > --- > --------------------------------------------------------------------- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast > and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Foswiki-discuss mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/foswiki-discuss ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
Re: How to stop fake registrations (lavabit.com accounts)
|
Am 27.12.2009 09:08, schrieb Kenneth Lavrsen:
> I do not agree this should be standard. > > First, I think it is the common assumption that Foswiki target group > is mainly businesses used for internal information and collaborarion. > And this means safely put behind a firewall. > > Default setup should not be annoying to our main target group. You are most probably right regarding the main target group but if Foswiki ever wants to increase its general use base it should also aim to address requirements for installations not behind a Firewall. They may not be default but it'll be good to have a way for activating such additional features without a need to think "deeply" about special groups and/or other "internal" stuff (especially important for new users). Regards, Ingo ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Foswiki-discuss mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/foswiki-discuss |
«
Return to Foswiki
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |