[wplug-internet] [wplug-board] WPLUG's information assets (membership rolls - part 2 of 3)

[Jim]

Vance, my biggest concern about members and other information security.  I
am opposed to having the information on a server where there may be access
by past members or vulnerabilities that may or may not have been known
over the years.  I agreed with Beth Lynn that it should be an "off WPlug
server/storage" arrangement.  Jim Harris

On Sun, 09 Jan 2011 01:47:14 -0500, Vance Kochenderfer <vkochend at nyx.net>
wrote:

> My plan to upgrade our membership tracking system was to develop
> a web interface (or reuse someone else's) that would fulfil the
> following design goals:
>
> A. Give members access to view their own information, and permit
> people to sign up online or make changes to their information.
>
> B. Restrict access to other members' information only to trusted
> individuals designated as admins (at least the Secretary).
>
> C. Following on A and B, integrate authentication with MediaWiki
> to avoid forcing members to create Yet Another Username and
> Password to gain access.
>
> D. Centralize the location of the canonical membership rolls so
> that the Secretary is not a single point of failure.  Others can
> be granted admin status.
>
> E. Require approval by an admin for new signups and changes to
> take effect.  This is to permit the Secretary to coordinate with
> the Treasurer for renewals, new applications, etc.  It is also to
> deter shenanigans.
>
> F. Maintain a complete history of changes.  This will permit the
> rollback of erroneous entries made accidentally or maliciously.
>
> G. Automatically give people a 90-day and 30-day notice that their
> memberships are expiring.
>
> H. Automatically manage subscriptions to the wplug-members mailing
> list based on the latest data in the system.
>
> I could not find an existing extension for MediaWiki which
> accomplishes or even closely approximates these goals, so I
> started work on developing one.  It is possible that one has
> appeared since I last worked on this (about two years ago).
> Attached is what I have so far.  It should be considered pre-alpha
> stage code.
>
> Currently, it does not address goals G and H.  I had planned to
> write a separate script to be run by cron which would accomplish
> those.  While the code is basically feature-complete for goals A
> through F, it is still untested.  I know that some additional work
> is needed to integrate it properly into MediaWiki as an extension.
>
> To avoid making this message any longer, I have separated out the
> technical discussion of how the system works to a separate readme
> file that is also attached.  Please have a look at it.
>
> Of course, placing this data on the web raises additional attack
> vectors.  The full member rolls are stored in a database table, as
> well as historical data.  Again, anyone with root access on the
> server can get them.  Access via the new interface page is limited
> to users in a special wiki user group called "memxadmin" (note
> that this is for wiki accounts, not login accounts on the server).
> Those admins added to this group will have full access, as well
> any wiki user in the "Sysop" group (because they can add
> themselves to any group).
>
> There is also the possibility of sniffing the unencrypted HTTP
> traffic of an admin while he's accessing the site.  In addition,
> anyone with a login account on the server who can obtain the
> database credentials will be able to access the table holding
> member information.  These are stored in the MediaWiki config
> file AdminSettings.php.  It is currently readable by any login
> account, though I believe it would be a simple matter to make it
> readable only to the apache user.
>
> My personal view is that we already invest a high level of trust
> in those individuals who have "Sysop" access to the wiki and root
> access to the server.  I am comfortable with the possibility that
> they may also access member information.  We only require that
> members provide their name and e-mail address in order to join.
> If they have specific privacy concerns, they are free to decline
> to provide other information.  (It is also possible to remove
> historical information from the database should an individual's
> situation so require.  This is a manual process, though.)
>
> The benefits gained are:
>
> 1. Greater transparency to members as to their current details and
> expiration date.  Currently, they have to request this information
> from the Secretary.
>
> 2. Ability to designate more than one person to approve new
> members or changes to existing member information.  Currently, the
> Secretary is a single point of failure on updating the membership
> rolls.  As an example, two members joined on Saturday but I have
> not updated the rolls yet.
>
> 3. Following on point 2, give others the ability to generate an
> up-to-date membership list if one is necessary for conducting
> WPLUG business.  Currently, the Secretary is the sole repository
> for the authoritative list, at least until he uploads it to the
> server.
>
> 4. Automatic notification of expiration dates to members.  Under
> the current system, the Secretary must remember to manually send
> out notices.
>
> 5. Requiring members to have a wiki account may encourage them to
> participate more in editing the wiki.
>
> I believe that these benefits weigh in favor of implementing my
> proposed system.  I recognize that it does create an increased
> risk of information leakage.  However, I think the risk is not out
> of balance with the sensitivity of the information.
>
> Please reply with your comments on the validity of the approach
> and any alternative proposals you may have.  Also, comments on the
> specific code itself are welcome, if we decide this is the correct
> path.
>
> Vance Kochenderfer        |  "Get me out of these ropes and into a
> vkochend at nyx.net          |   good belt of Scotch"    -Nick Danger