Quantcast

How to stop fake registrations (lavabit.com accounts)

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to stop fake registrations (lavabit.com accounts)

Matthias Wientapper
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Martin Cleaver
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,

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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Foswiki's registration process is outdated

Matthias Wientapper
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Foswiki's registration process is outdated

Matthias Wientapper
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Foswiki's registration process is outdated

Koen Martens
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Foswiki's registration process is outdated

Filippo Salustri
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:
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Paul W Harvey
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Foswiki's registration process is outdated

Martin Cleaver
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Filippo Salustri
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,

> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Foswiki's registration process is outdated

Filippo Salustri
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
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



--
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Sven Dowideit
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Filippo Salustri
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/



--
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Sven Dowideit
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Anton Ivanov-2
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Martin Cleaver
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Matthias Wientapper
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Luca Fini
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Raymond Lutz
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

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.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to stop fake registrations (lavabit.com accounts)

Ingo Kappler
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
12
Loading...