[drupal-devel] [bug] Remove drupal module from core

[Robin Monks]

But wouldn't the encrypted password prevent this senario?

Robin

On 9/20/05, robertDouglass <drupal-devel at drupal.org> wrote:
>
> Issue status update for
> http://drupal.org/node/31716
> Post a follow up:
> http://drupal.org/project/comments/add/31716
>
> Project: Drupal
> Version: cvs
> Component: drupal.module
> Category: bug reports
> Priority: normal
> Assigned to: Anonymous
> Reported by: robertDouglass
> Updated by: robertDouglass
> Status: patch (code needs review)
>
> The more I think about it, the more I conclude that Drupal.org<http://Drupal.org>should
> also drop dist. auth. support, or find better security solutions.
> Here's an example scenerio to provoke discussion. Gerhard always logs
> on to drupal.org <http://drupal.org> as killes at www.drop.org. AFAIK, these
> sites are now on
> two separate servers, and therefore probably have different security
> profiles. Now, just as conjecture, let us suppose that the server on
> which drop.org <http://drop.org> is run gets compromised and someone is
> able to steal
> Gerhard's password. They now have a big cat in the bag: drupal.org<http://drupal.org>
> .
> They'd be able to become site/cvs admins for drupal.org<http://drupal.org>,
> something
> which we probably don't want. In the end, if we have no way to say
> which sites can be trusted to do authentication, it is a bad idea
> allowing anyone to use this in conjunction with drupal.org<http://drupal.org>
> .
>
>
> Another example:
> http://kerneltrap.org/user/2524
> What if Jeremy's server were compromised (or perhaps Jeremy is just
> really evil and nobody knows ;-))? In either case, someone would be
> able to log into drupal.org <http://drupal.org> with the UnConeD username
> - not a really
> attractive idea.
>
>
> PLEASE TELL ME I'M WRONG! Or remove the module.
>
>
>
>
> robertDouglass
>
>
>
> Previous comments:
> ------------------------------------------------------------------------
>
> Tue, 20 Sep 2005 07:14:52 +0000 : robertDouglass
>
> Attachment: http://drupal.org/files/issues/drupalmod.patch (11.15 KB)
>
> The drupal module does two things; it implements distributed
> authentication and it lets you run a "directory server". These sound
> great in the features list, but the implementation of both features is
> weak and poses the real risk of exposing Drupal users to identity
> theft.
>
>
> Here is an excerpt from my writings on the module:
>
>
> Distributed authentication
> Drupal distributed authentication is a way to save site users the extra
> steps of creating redundant accounts on multiple sites.
>
>
> (snip... we know how it works :-)
>
>
> There are some limitations and concerns about the current
> implementation of distributed authentication. It would be relatively
> easy for someone to alter the code of their site to save a record of
> the passwords of users who log in. This is true of any website you
> visit, Drupal or otherwise. As long as the username and password only
> buys access to that very site, there is little incentive to do this.
> If, however, it would allow the malicious person to log into other
> sites as well, in this case any Drupal site that has the drupal module
> enabled, the incentive is greater and the potential loss or damage
> greater. The attacker would be able to masquerade on those sites using
> your user identity and execute actions on your behalf.
>
>
> CAUTION Drupal's distributed authentication is inherently insecure. If
> you do not know that you can trust the owner(s) of a particular site,
> never use your distributed authentication (Drupal id) to log into it.
>
>
> Running a directory server
> The drupal module offers a simple service by which other Drupal sites
> can announce their existence, or "ping" a central server on a regular
> basis. While there are many possible applications of such a service,
> the most prominent use is the now defunct Drupal sites page on
> Drupal.org <http://Drupal.org> which was simply a long list of sites that
> run Drupal.
>
>
> In practice, any site that has the drupal module enabled can function
> as a directory server. When another site pings the site, the remote
> site's name, slogan and mission are added to the list of sites. A
> useful application of a directory server might be on a college or
> university where individual labs or departments are setting up many
> different Drupal sites. Each one could ping a central server at the
> university to compile a list of all the various sites as they spring
> up.
>
>
> In its current state, the service lacks some basic features. There is
> no way for the administrator to block a certain site from pinging and
> being added to the list. Nor is there a way to limit the incoming pings
> to a certain set of domains or IP addresses. The potential to make a
> truly useful directory server service exists, though, and anyone is
> encouraged to participate in discussions and development at Drupal.org<http://Drupal.org>
> .
>
>
> -----------------------
>
>
> I've come to the conclusion that a module that is this weak should be
> offered as a contributed module, not as core. If it weren't in core, I
> wouldn't bother writing about it because it is too weak, and poses a
> real security threat. My recommendation is that it be placed in the
> contributions repository as an example of how distributed auth. for
> those enterprising individuals who might want to improve upon it.
>
>
>
>
> ------------------------------------------------------------------------
>
> Tue, 20 Sep 2005 10:19:32 +0000 : robertDouglass
>
> tasks don't send mail? Setting to bug report.
>
>
>
>
>


--
Robin Monks,
CSL Web Administrator
robin at civicspacelabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drupal3.drupal.org/pipermail/development/attachments/20050921/e593a637/attachment.htm